On Wed, Nov 13, 2013 at 12:30 AM, Steven Bosscher wrote:
> Hello,
>
> Here is a non-comprehensive list of macros that are used with a
> function passed to the macro's argument, and the macro evaluates that
> argument at least twice:
>
> gimple.c: && (CONVERT_EXPR_CODE_P (gimple_assign_rhs
On Mon, Nov 11, 2013 at 10:27 PM, Matthias Klose wrote:
> Am 11.11.2013 11:06, schrieb Andrew Haley:
>> On 11/11/2013 03:22 AM, Jeff Law wrote:
>>> On 11/09/13 08:55, Andrew Haley wrote:
On 11/09/2013 03:44 PM, Alec Teal wrote:
> If Java must go, and it must have a replacement Ada makes s
On Wed, Nov 13, 2013 at 7:50 AM, Jeff Law wrote:
> On 11/12/13 01:27, Eric Botcazou wrote:
>>>
>>> From what I can see, bootstrapping with Ada is slower than bootstapping
>>> with Java, by around 15%. Again this is on one of my slower boxes, but
>>> the results clearly show building Ada & its ru
On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
> On 11/13/2013 10:56 AM, Richard Biener wrote:
>> At least we don't need a Java source code frontend, no? Just keeping
>> the bytecode compiler and GIJ should be enough? That way we can
>> strip the classpath cop
On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher wrote:
> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>> Well, he doesn't even consider that the exact same "tree rant" applies
>> to frontend code.
>
> That's not entirely true, either. Most fro
On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
> On 11/13/2013 11:29 AM, Richard Biener wrote:
>> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
>>> On 11/13/2013 10:56 AM, Richard Biener wrote:
>>>> At least we don't need a Java source code f
On Wed, Nov 13, 2013 at 1:07 PM, Eric Botcazou wrote:
>> Eric, would emitting GIMPLE from gigi make that a lot more
>> complicated? That is, would you prefer to have an even
>> higher-level early GIMPLE (considering stuff like TARGET_EXPR
>> and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean priva
On Wed, Nov 13, 2013 at 1:51 PM, Andrew Haley wrote:
> On 11/13/2013 12:37 PM, Richard Biener wrote:
>> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
>>> On 11/13/2013 11:29 AM, Richard Biener wrote:
>>>> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote
On Wed, Nov 13, 2013 at 2:00 PM, Richard Biener
wrote:
> On Wed, Nov 13, 2013 at 1:51 PM, Andrew Haley wrote:
>> On 11/13/2013 12:37 PM, Richard Biener wrote:
>>> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
>>>> On 11/13/2013 11:29 AM, Richard Biener wro
On Wed, Nov 13, 2013 at 2:37 PM, Andrew Haley wrote:
> On 11/13/2013 01:22 PM, Jakub Jelinek wrote:
>> On Wed, Nov 13, 2013 at 02:01:52PM +0100, Richard Biener wrote:
>>>>> Really? Wouldn't it make more sense for people to check out what they
>>>>> ne
On Wed, Nov 13, 2013 at 5:20 PM, Jeff Law wrote:
> On 11/13/13 09:00, Tom Tromey wrote:
>>>
>>> "Jeff" == Jeff Law writes:
>>
>>
>> Jeff> Given the problems Ian outlined around adding Go to the default
>> Jeff> languages and the build time issues with using Ada instead of Java,
>> Jeff> I
On Wed, Nov 13, 2013 at 5:50 PM, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote:
>> On Wed, 13 Nov 2013, Jeff Law wrote:
>>
>> > On 11/13/13 08:59, Joseph S. Myers wrote:
>> > > On Wed, 13 Nov 2013, Steven Bosscher wrote:
>> > >
>> > > > Really the best plac
On Fri, Nov 15, 2013 at 2:16 PM, Bingfeng Mei wrote:
> Hi,
> In loop vectorization, I found that vectorizer insists on loop peeling even
> our target supports misaligned memory access. This results in much bigger
> code size for a very simple loop. I defined
> TARGET_VECTORIZE_SUPPORT_VECTOR_MI
"Ondřej Bílka" wrote:
>On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
>> Also keep in mind that usually costs go up significantly if
>> misalignment causes cache line splits (processor will fetch 2 lines).
>> There are non-linear costs of filling up the store queue in modern
>> o
DJ Delorie wrote:
>
>> Everything handling __int128 would be updated to work with a
>> target-determined set of types instead.
>>
>> Preferably, the number of such keywords would be arbitrary (so I
>suppose
>> there would be a single RID_INTN for them) - that seems cleaner than
>the
>> system
"Ondřej Bílka" wrote:
>On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote:
>> "Ondřej Bílka" wrote:
>> >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
>>
>> IIRC what can still be seen is store-buffer related slow
even be where the bitsize points to.
> >
> > However, having just done a few greps, it looks like this case was just the
> > one that i found while doing the wide-int work, there may be several more of
> > these cases. Just in fold-const, there are a couple in fold_binary_loc.
> > The one in tree.c:int_fits_type_p looks particularly wrong.
> >
> > I think that there are also several in tree-vect-patterns.c.
> >
> > Kenny
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
On Mon, Nov 18, 2013 at 8:11 AM, Florian Weimer wrote:
> * Jeff Law:
>
>>> Is this new in C11? Does it apply to functions such as strnlen as well?
>
>> No, it's C99 I think. There was a clarification which came in after
>> C99 which clarified that even if the length is zero, the pointers must
>>
On Mon, Nov 18, 2013 at 3:24 PM, Jeff Law wrote:
> On 11/18/13 04:08, Richard Biener wrote:
>>>
>>> I'd say that turning memset (0, '\0', 0) into a trap is bad from a QOI
>>
>> perspective. Jeff, is there an easy way to avoid this? Testcase:
&g
On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely wrote:
> On 21 November 2013 21:17, Peter Bergner wrote:
>> On Thu, 2013-11-21 at 16:03 -0500, David Edelsohn wrote:
>>> Looks like another issue for the libsanitizer maintainers.
>>
>> I've been doing bootstraps, but didn't see this because the
>>
Status
==
The trunk is now in Stage 3. To repeat what that means: the trunk
is open for general bugfixing, no new features should be added
at this point. For exceptions consult your friendly release
managers.
We have been in Stage 1 for 8 months now. Now is time to look
into one of the g
On Fri, Nov 22, 2013 at 12:03 PM, Bingfeng Mei wrote:
> Well, in your modified example, it is still due to jump threading that produce
> code of bad control flow that cannot be if-converted and vectorized, though in
> tree-vrp pass this time.
>
> Try this
> ~/install-4.8/bin/gcc vect-ifconv-2.c -
On Fri, Nov 22, 2013 at 1:36 PM, Konstantin Serebryany
wrote:
> On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
>> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
>>> > As my bugreport is being ignored it would help if one ouf our
>>>
>>> Sorry. Which one?
>>
>> I bel
On Fri, Nov 22, 2013 at 6:13 PM, Bingfeng Mei wrote:
> So if we are about to fix this in if-conversion, we need to do both in tree &
> rtl as both ifcvt & ce passes cannot handle it.
>
> I am still not convinced jump threading is good for target with predicated
> execution (assuming no fix for i
On Sun, Dec 1, 2013 at 1:29 PM, Richard Sandiford
wrote:
> FWIW, here are some numbers comparing the times various
> --enable-checking=release versions of cc1plus take to compile
> a set of .ii inputs at -O2. The versions are:
>
> (a) wide-int r205263, where the last merge was made
> (b) current
On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
> http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html
>
> FAILED: Bootstrap (build config: lto; languages: fortran; trunk revision
> 205557) on x86_64-unknown-linux-gnu
>
> In function 'release',
> inlined from 'release' at /home/toon/
Eric Botcazou wrote:
>> For code:
>>
>> unsigned char foo (unsigned char c)
>> {
>>return (c >= '0') && (c <= '9');
>> }
>>
>> we end up generating:
>>
>> sub r0, r0, #48
>> uxtbr0, r0
>> cmp r0, #9
>> movhi r0, #0
>> movls r0, #1
On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders wrote:
> On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
>> On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
>> > http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html
>> >
>> >
On Fri, Dec 6, 2013 at 9:42 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Well, I think making the simplify-rtx code conditional on the target
>>> would be the wrong way to go. If we really can't live with it being
>>> unconditional then I think we should revert it. But like I say I
On Fri, Dec 6, 2013 at 9:30 AM, Konstantin Vladimirov
wrote:
> Hi,
>
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
>
> Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with o
s SCEV infrastructure (guessing scalar evolutions?) and what
> files/passes to look in?
tree-scalar-evolution.c, look at where it handles MULT_EXPR but
lacks LSHIFT_EXPR support.
Richard.
> ---
> With best regards, Konstantin
>
> On Fri, Dec 6, 2013 at 2:10 PM, Richard Biener
On Wed, 4 Dec 2013, Vidya Praveen wrote:
> Hi Richi,
>
> Apologies for the late response. I was on vacation.
>
> On Mon, Oct 14, 2013 at 09:04:58AM +0100, Richard Biener wrote:
> > > void
> > > foo (int *__restrict__ a,
> > > int *__restrict__
am working on, it
> is important. What would you advise?
You need to look at IVOPTs and how it arrives at the choice of
induction variables.
Richard.
> ---
> With best regards, Konstantin
>
> On Fri, Dec 6, 2013 at 2:25 PM, Richard Biener
> wrote:
>> On Fri, Dec 6, 20
On Tue, Dec 10, 2013 at 4:03 PM, Umesh Kalappa wrote:
> Hi All,
>
> Below is the patterns defined for the mov and add instruction
> .
> [(set (match_operand:HI 0 "general_mov_operand" "=r,rRA")
> (match_operand:HI 1 "general_mov_operand" "rRAi,ri"))]
> ""
> {
>
> }
>
On Tue, Dec 10, 2013 at 7:42 PM, DJ Delorie wrote:
>
>> (For the types you do have, there's a need to define C++ name mangling.
>
> I mentioned this before, and I don't have a good solution for it.
> Both C++ and LTO need a mangled form of __intN types.
LTO shouldn't need any of this. Ideally we
On Thu, Dec 12, 2013 at 8:19 PM, Steve Ellcey wrote:
> I have a question about the partial pre (-ftree-partial-pre) optimization
> that was added in GCC 4.8. I have noticed that this optimization is slowing
> down the bitmnp01 benchmark in the EEMBC1.1 suite on MIPS. I see this with
> the 4.8 GC
Steve Ellcey wrote:
>On Fri, 2013-12-13 at 11:26 +0100, Richard Biener wrote:
>> On Thu, Dec 12, 2013 at 8:19 PM, Steve Ellcey
>wrote:
>> > I have a question about the partial pre (-ftree-partial-pre)
>optimization
>> > that was added in GCC 4.8. I have n
Status
==
The trunk remains in Stage 3 until the end of January at which
point we enter regression-and-doc-fixes-only mode.
Quality is improving slowly as we are still getting a lot of
new regressions, both due to increased testing and still merging
a lot of code (please slow down and consid
Sandeep K Chaudhary wrote:
>Thanks for the reply Marc !
>
>If I place my pass before ccp then I guess I have to implement the
>means to perform calculations on my own so that it can duplicate the
>functionality of ccp, right? I will also look at the source code to
>see if I can modify the source c
On Tue, Jan 7, 2014 at 4:47 PM, Paulo Matos wrote:
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
>> Matos
>> Sent: 13 November 2013 16:14
>> To: Andrew Haley
>> Cc: gcc@gcc.gnu.org
>> Subject: RE: Infinite number of iterations in loo
On Wed, Jan 8, 2014 at 3:09 PM, Paulo Matos wrote:
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: 08 January 2014 11:03
>> To: Paulo Matos
>> Cc: Andrew Haley; gcc@gcc.gnu.org
>> Subject: Re: Infinite num
rstand why GCC is generating this extra basic block
> however it looks like a regression. Block 5 could disappear and insn 55
> rewritten as (replaced reg101 by reg96):
>
> (set (reg:SI 96 [ D.3280 ])
> (plus:SI (reg:SI 109 [ D.3280 ])
>
On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
wrote:
> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>>
>> On 10/01/14 08:49, Bernd Edlinger wrote:
>>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
On 09/01/14 08:26, Bernd Edlinger wrote:
> Hi,
>
> On Thu, 9
Jeff Law wrote:
>On 01/10/14 10:03, Paulo Matos wrote:
>>
>>
>> Paulo Matos
>>
>>
>>> -----Original Message-
>>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>> Sent: 10 January 2014 13:25
>>> To: Paulo Mat
On Fri, Jan 3, 2014 at 11:18 AM, BELBACHIR Selim
wrote:
> Hi,
>
> I noticed a problem in gcc/testsuite/g++.dg/lto/lto.exp
>
> If the target does not support LTO (check_effective_target_lto) a brutal
> return is performed so the mathlib variable modified in lto_init will not be
> restored properl
On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi wrote:
> We are writing a GIMPLE pass and would like to use some information computed
> in
> pass_vectorize. However, we are not able to use the data structures which
> gets populated in pass_vectorize
> because the information is not made available acr
On Mon, Jan 20, 2014 at 11:17 AM, Swati Rathi wrote:
> On Monday 20 January 2014 02:20 PM, Richard Biener wrote:
>>
>> On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi
>> wrote:
>>>
>>> We are writing a GIMPLE pass and would like to use some information
On Wed, Jan 22, 2014 at 1:20 PM, Bingfeng Mei wrote:
> Hi,
> I noticed there is a regression of 4.8 against ancient 4.5 in vectorization
> on our port. After a bit investigation, I found following code that prefer
> even|odd version instead of lo|hi one. This is obviously the case for AltiVec
>
On Fri, Jan 24, 2014 at 6:47 PM, Bingfeng Mei wrote:
> Hi,
> I experienced an issue in our port, which I suspected due to bugs
> in ptr_difference_const & split_address_to_core_and_offset. Basically,
> ptr_difference_const, called by ivopts pass, tries to evaluate
> whether e1 & e2 differ by a con
my head - so better double-check
in the vectorizer sources.
Richard.
> Bingfeng
>
>
>
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 28 January 2014 11:02
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: VEC_WIDEN_MU
nt
> + vec_widen_(s|u)mul_even/odd pair if it is less efficient
> + than hi/lo pair.
> +
> 2014-01-28 Richard Biener
>
> Revert
> Index: gcc/doc/md.texi
> ===
> --- gcc/doc/md.texi
On Thu, Jan 30, 2014 at 3:57 PM, Conrad S wrote:
> Jonathan Wakely wrote:
>> Only if you don't read the pages properly.
>> "Important: GCC's support for C++11 is still experimental. "
>> "GCC provides experimental support for the 2011 ISO C++ standard."
>> Anyway, removing it from the list would a
On 1/31/14 4:02 PM, Bingfeng Mei wrote:
> Hi,
> I got this simple example to vectorize. Somehow, GCC (4.8) generates loop
> version because
> it cannot determine alias between acc[i] write and x[i].real read. It is
> pretty obvious to me that they are not aliased based on TBAA information.
>
> t
Because the gcc memory model allows the dynamic type of a memory location to
change by a store.
That in turn is the only sensible way of supporting c++ placement new.
Richard.
>
>Bingfeng
>
>-Original Message-
>From: Richard Biener [mailto:rguent...@suse.de]
>Sent: 3
Status
==
After two months of Stage 3 the trunk is now in release-branch mode
which means only patches fixing regressions and documentation issues
are appropriate.
We're getting a lot of bugs fixed and thus the quality data below
shows we are on track for a release around the beginning of Ap
On Mon, 3 Feb 2014, Jakub Jelinek wrote:
> On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
> > If it is just for C++ placement new, why don't implement it as a lang_hook.
> > Now other languages such as C have to be made conservative and produce worse
> > code.
But if you combine a
On Mon, 3 Feb 2014, Florian Weimer wrote:
> On 02/03/2014 10:59 AM, Jakub Jelinek wrote:
> > On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote:
> > > If it is just for C++ placement new, why don't implement it as a
> > > lang_hook.
> > > Now other languages such as C have to be made con
On Mon, 3 Feb 2014, Richard Biener wrote:
> And note that for the case in question we
> can derive non-aliasing because with
>
> p[i] += q[i];
>
> p[i] is both read _and_ written in the same iteration thus
> it cannot have the dynamic type of q[i] before it's stor
DRs catching the other) and try to
prove that you can't construct one that causes a[] to read from a
location that b[] stored to but the vectorizer would introduce such
false dependence. I think that's not possible (fingers crossing ;)).
Richard.
>
> Bingfeng
> -Original
> se :-).
I already have done that (PR60043)
Richard.
> Bingfeng
>
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: 03 February 2014 13:16
> To: Bingfeng Mei
> Cc: Florian Weimer; Jakub Jelinek; gcc@gcc.gnu.org
> Subject: RE
On Tue, Feb 4, 2014 at 5:27 PM, Bingfeng Mei wrote:
> Hi,
> One of biggest issues we have with GCC vectorization is bloated code size.
> For example, vectorized version is 2.5 times of non-vectorized one for the
> following simple code. One reason is that GCC often creates one loop copy
> because
On Tue, Feb 11, 2014 at 10:20 PM, Jan Hubicka wrote:
>> >> Since both toolchains do the magic, binutils has no incentive to
>> >> create any automatic detection of objects.
>>
>> It is mostly a historical decision. At the time the design was for the
>> plugin to be matched to the compiler, and so
On Wed, Feb 12, 2014 at 7:21 AM, Albert Cahalan wrote:
> I had a problem that got solved in an ugly way. I think gcc ought
> to provide a few ways to make a nicer solution.
>
> There was an array of structs roughly like so:
>
> struct{int w;float x;char y[4];short z[2];}foo[512][4];
>
> The types
On February 13, 2014 8:07:16 AM GMT+01:00, chronicle
wrote:
>Hi PPL i developed a plugin that produces the following gimple
>
>test ()
>{
> int selected_fnc_var_.3;
> int random_Var.2;
> int D.2363;
> int _1;
>
> :
> random_Var.2_2 = rand ();
> selected_fnc_var_.3_3 = random_Var.2_
On Wed, Feb 12, 2014 at 5:22 PM, Jan Hubicka wrote:
>> On Wed, 12 Feb 2014, Richard Biener wrote:
>>
>> > What about instead of our current odd way of identifying LTO objects
>> > simply add a special ELF note telling the linker the plugin to use?
On Mon, Jan 27, 2014 at 8:40 PM, Tobias Grosser wrote:
> On 01/27/2014 08:29 PM, Tobias Burnus wrote:
>>
>> Hello,
>>
>> motivated by the recent MPC 1.0.2 announcement, I looked at
>> ./contrib/download_prerequisites and also at
>> ftp://gcc.gnu.org/pub/gcc/infrastructure/ to see which versions ar
On Thu, Feb 13, 2014 at 2:20 PM, Tobias Grosser wrote:
> On 02/13/2014 08:19 AM, Richard Biener wrote:
>>
>> On Mon, Jan 27, 2014 at 8:40 PM, Tobias Grosser wrote:
>>>
>>> On 01/27/2014 08:29 PM, Tobias Burnus wrote:
>>>>
>>>>
>>>
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> Hi,
> I have noticed that record_component_aliases is called during LTO time and it
> examines contents of BINFO:
> 0x5cd7a5 record_component_aliases(tree_node*)
> ../../gcc/alias.c:1005
> 0x5cd4a9 get_alias_set(tree_node*)
> ../../gcc/alia
On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> Given a specific VAR_DECL tree node, I need to find out whether
> its type is built in or not. Up to now I have
>
> tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
>
On Fri, Feb 14, 2014 at 2:23 PM, Allan Sandfeld Jensen
wrote:
> Hello gcc
>
> I have been looking at optimizations of pixel-format conversion recently and
> have noticed that gcc does take advantage of SSE4a extrq, BMI1 bextr TBM
> bextri or BMI2 pext instructions when it could be useful.
>
> As f
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> > > This smells bad, since it is given a canonical type that is after the
> > > structural equivalency merging that ignores BINFOs, so it may be
> > > completely
> > > different class with completely different bases than the original. Bases
> > > are
>
On Sat, 15 Feb 2014, Jan Hubicka wrote:
> > > > This smells bad, since it is given a canonical type that is after the
> > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > completely
> > > > different class with completely different bases than the original.
> > > > Ba
On Mon, 17 Feb 2014, Jan Hubicka wrote:
> > On Fri, 14 Feb 2014, Jan Hubicka wrote:
> >
> > > > > This smells bad, since it is given a canonical type that is after the
> > > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > > completely
> > > > > different class with c
On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt wrote:
> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt
>> wrote:
>> > Given a specific VAR_DECL tree node, I need to find out whether
>> > its type
On February 17, 2014 7:18:15 PM GMT+01:00, "Paul E. McKenney"
wrote:
>On Wed, Feb 12, 2014 at 07:12:05PM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote:
>> > You need volatile semantics to force the compiler to ignore any
>proofs
>> > it might oth
On Mon, 17 Feb 2014, Jan Hubicka wrote:
> >
> > Yeah, ok. But we treat those types (B and C) TBAA equivalent because
> > structurally they are the same ;) Luckily C has a "proper" field
> > for its base (proper means that offset and size are correct as well
> > as the type). It indeed has DECL
On Tue, 18 Feb 2014, Richard Biener wrote:
> On Mon, 17 Feb 2014, Jan Hubicka wrote:
>
> > >
> > > Yeah, ok. But we treat those types (B and C) TBAA equivalent because
> > > structurally they are the same ;) Luckily C has a "proper" field
> >
On Tue, 18 Feb 2014, Jan Hubicka wrote:
> > > Non-ODR types born from other frontends will then need to be made to
> > > alias all the ODR variants that can be done by storing them into the
> > > current canonical type hash.
> > > (I wonder if we want to support cross language aliasing for non-P
On Wed, 19 Feb 2014, Jan Hubicka wrote:
> > On Tue, 18 Feb 2014, Jan Hubicka wrote:
> >
> > > > > Non-ODR types born from other frontends will then need to be made to
> > > > > alias all the ODR variants that can be done by storing them into the
> > > > > current canonical type hash.
> > > > >
On Mon, Feb 24, 2014 at 4:57 PM, Linus Torvalds
wrote:
> On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
> wrote:
>>
>> Let me think about it some more, but my gut feel is that just tweaking
>> the definition of what "ordered" means is sufficient.
>>
>> So to go back to the suggested ordering ru
On Wed, Feb 26, 2014 at 11:32 AM, Andrew Haley wrote:
> Say you have a pointer:
>
> int *p;
>
> and an inline asm that writes to a block of memory
>
> __asm__("\t0:\n"
> "\tstr wzr, [%2, #4]!\n"
> "\tsub %1, %1, #1\n"
> "\tcbnz %1, 0b\n"
> : "=m"(*p), "+r"
On Wed, Feb 26, 2014 at 12:10 PM, Andrew Haley wrote:
> On 02/26/2014 10:51 AM, Richard Biener wrote:
>> But yes, technically you write p[0] here but as "m" merely builds
>> an address to the memory I'd say that we have to treat any "m"
>>
I've been hacking on a prototype that generates matching and
simplification code from a meta-description. The goal is
to provide a single source of transforms currently spread
over the compiler, mostly fold-const.c, gimple-fold.c and
tree-ssa-forwprop.c. Another goal is to make these transforms
On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou wrote:
>> After some investigation, we discovered that this behavior is caused by
>> big hammer in gcc/cse.c:
>> /* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
>> if (NONJUMP_INSN_P (insn)
>> && volatile_insn_p (PA
On Fri, Feb 28, 2014 at 9:51 AM, Eric Botcazou wrote:
>> So, the main question is not about triggering condition, but about the
>> behavior itself. Is it correct to flush and reload all constants ? They are
>> constants after all, they are even not stored in .data section but inlined
>> in the co
On Fri, Feb 28, 2014 at 10:23 AM, Eric Botcazou wrote:
>> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
>> make sense to be overly conservative at the RTL CSE level. Thus I think we
>> can just remove this barrier completely.
>
> Not clear to me, what happens e.g. f
On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni
wrote:
> Hi, I am an undergraduate student at University of Pune, India, and would
> like to work on moving folding patterns from fold-const.c to gimple.
I've seen the entry on our GSoC project page and edited it to discourage
people from workin
On Mon, Mar 3, 2014 at 9:40 AM, Jakub Jelinek wrote:
> On Mon, Mar 03, 2014 at 11:02:14AM +0800, lin zuojian wrote:
>>I wrote a test code like this:
>> void foo(int * a)
>> {
>> a[0] = 0xfafafafb;
>> a[1] = 0xfafafafc;
>> a[2] = 0xfafafafe;
>> a[3] = 0xfafafaff;
>> a[4] = 0
On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
> On 28/02/14 13:19, Richard Sandiford wrote:
>> Georg-Johann Lay writes:
>>> Notice that in code1, func might contain such asm-pairs to implement
>>> atomic operations, but moving costly_func across func does *not*
>>> affect the interrupt resp
On Fri, 28 Feb 2014, Marc Glisse wrote:
> On Thu, 27 Feb 2014, Richard Biener wrote:
>
> > I've been hacking on a prototype that generates matching and
> > simplification code from a meta-description. The goal is
> > to provide a single source of transforms
On Fri, 28 Feb 2014, Diego Novillo wrote:
> On Thu, Feb 27, 2014 at 9:34 AM, Richard Biener wrote:
>
> > Comments or suggestions?
>
> On the surface it looks like a nice idea. However, I would like to
> understand the scope of this. Are you thinking of a pattern matcher
On Fri, 28 Feb 2014, Kai Tietz wrote:
> Hmm, this all reminds me about the approach Andrew Pinski and I came
> up with two years ago.
You are talking about the gimple folding interface? Yes, but it's
more similar to what I proposed before that.
> All in all I think it might be worth to
> exp
On Mon, Mar 3, 2014 at 1:53 PM, David Brown wrote:
> On 03/03/14 11:49, Richard Biener wrote:
>> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
>>> On 28/02/14 13:19, Richard Sandiford wrote:
>>>> Georg-Johann Lay writes:
>>>>> Notice that i
On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> Hi,
> in include/linux/compiler-gcc.h :
>
> /* Optimization barrier */
> /* The "volatile" is due to gcc bugs */
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> The comment of Linux says this is a gcc bug.But will any sane comp
On Tue, Mar 4, 2014 at 10:19 AM, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> wrote:
>> On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
>>> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
>>> > Hi,
>>
On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
wrote:
> On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
>> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> >> > So the bug was probably fixed more than 15 years ago.
>> > Probably :)
>> >
>> > But the __volatile__ shoud do
On Tue, Mar 4, 2014 at 1:01 PM, Hans-Peter Nilsson wrote:
> On Tue, 4 Mar 2014, Yury Gribov wrote:
>> Richard wrote:
>> > volatile __asm__("":::"memory")
>> >
>> > is a memory barrier and a barrier for other volatile instructions.
>>
>> AFAIK asm without output arguments is implicitly marked as vo
On Mon, 3 Mar 2014, Kai Tietz wrote:
> 2014-03-03 12:33 GMT+01:00 Richard Biener :
> > On Fri, 28 Feb 2014, Kai Tietz wrote:
> >
> >> Hmm, this all reminds me about the approach Andrew Pinski and I came
> >> up with two years ago.
> >
> > You are tal
On Tue, 4 Mar 2014, Marc Glisse wrote:
> On Mon, 3 Mar 2014, Richard Biener wrote:
>
> > > How do I restrict some subexpression to have
> > > a single use?
> >
> > This kind of restrictions come via the valueize() hook - simply
> > valueize to NUL
On Thu, Mar 6, 2014 at 7:17 PM, Prathamesh Kulkarni
wrote:
> On Thu, Mar 6, 2014 at 6:13 PM, Richard Biener
> wrote:
>> On Thu, Mar 6, 2014 at 1:11 PM, Prathamesh Kulkarni
>> wrote:
>>> On Mon, Mar 3, 2014 at 3:32 PM, Richard Biener
>>> wrote:
>>>
1601 - 1700 of 2616 matches
Mail list logo
