Hi,
I'm sitting on this since quite some time already and always missed stage
1. This implements support for vectorizing strided stores with unknown
but loop invariant stride, like:
sumit (float * __restrict dest,
float * __restrict src, float * __restrict src2,
int stride, int n
Hi,
On Mon, 4 May 2015, Xinliang David Li wrote:
> The use case proposed by Sri allows user to selectively eliminate PLT
> overhead for hot external calls only.
Yes, but only _because_ his approach doesn't use lazy binding. With the
full solution such restriction to a subset of functions isn't
Hi,
On Thu, 30 Apr 2015, Sriraman Tallam wrote:
> We noticed that one of our benchmarks sped-up by ~1% when we eliminated
> PLT stubs for some of the hot external library functions like memcmp,
> pow. The win was from better icache and itlb performance. The main
> reason was that the PLT stub
Hi,
On Sun, 22 Feb 2015, Tom de Vries wrote:
> Btw, I'm wondering if as run-time optimization we can tentatively set
> PROP_gimple_lva at the start of the gimple pass, and unset it in
> gimplify_va_arg_expr. That way we would avoid the loop in
> expand_ifn_va_arg_1 (over all bbs and gimples) i
Hi,
On Thu, 20 Nov 2014, Richard Biener wrote:
> > I don't think this API will make the non-C++-fans happier; I think the
> > objection to the work I just merged is that it's adding more C++ than
> > those people are comfortable with.
>
> How so? It's already super-ugly in those views. We deci
Hi,
On Thu, 20 Nov 2014, Patrick Palka wrote:
> > -wrapper is specifically also for invoking cc1 with gdb from the
> > driver (that's the usecase documented with -wrapper), so it better
> > should work as intended. I don't know what problems Patrick had with
> > that, though. For me gcc -wra
Hi,
On Mon, 17 Nov 2014, Richard Biener wrote:
> This means I can no longer interrupt a compile that is running too long?
No, that's not what it means, cc1 will also get the SIGINT.
> You should instead debug the actual compiler, not the driver.
-wrapper is specifically also for invoking cc1
Hi,
On Tue, 4 Nov 2014, Jeff Law wrote:
> They still need to agree on the layout of the structure. And assuming
> it'll always be memcpy perhaps isn't wise. Consider the possibility
> that one day (perhaps soon) the host and GPU may share address space &
> memory.
Not only soon, there is al
Hi,
On Mon, 27 Oct 2014, Aldy Hernandez wrote:
> Here I use a new tree bit (BLOCK_DIE) to store the DIE<->block
> relationship. This will have to be adapted and streamed for LTO.
You might consider using an on-the-side tree->hash map. Saves memory when
not generating debug info (there can be
Hi,
On Fri, 19 Sep 2014, Aldy Hernandez wrote:
> Michael, I really don't understand the need for this change in your original
> patch. I don't know if this was a temporary testing change or what.
I'm pretty sure it was temporary testing, when I still was finding my way
through dwarf2out limita
Hi,
our kernel guys saw this problem when they used an asm goto to implement a
conditional where the then-block was empty. RTL ifcvt happily goes on and
removes the whole block and the jump instruction, even though it has
side-effects (as marked with the volatility). Patch below fixes it by
Hi,
On Thu, 10 Jul 2014, Jeff Law wrote:
> > The insight to note is, that undefined SSA names should really be
> > coalesced with something (otherwise you lost an optimization opportunity),
> > but it doesn't matter with _what_ each use of the undefined name is
> > coalesced, you can even identif
Hi,
On Thu, 10 Jul 2014, Richard Biener wrote:
> Apart from the out-of-SSA patch you proposed elsewhere a possibility
> is to simply never mark undefined SSA names as
> SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those
> as must-coalesce).
The insight to note is, that undefined SSA names sh
Hi,
On Mon, 2 Jun 2014, Ilya Enkovich wrote:
> > There is exactly one place (except for the self-recursive ones) where
> > you call the new store_expr with a non-null argument for bounds
> > target, and it seems to be only necessary for when some sub-expression
> > of the RHS is a call. Can y
Hi,
On Mon, 2 Jun 2014, Ilya Enkovich wrote:
> This patch adds support for input bounds, call bounds args and returned
> bounds in expand pass.
>
> * expr.h (store_expr): Add param for bounds target.
There is exactly one place (except for the self-recursive ones) where you
call the new
Hi,
On Mon, 12 May 2014, David Malcolm wrote:
> The "gfoo" type names are pleasantly terse, though I'm a little unhappy
> about how they no longer match the prefix of the accessor functions e.g.
> gimple_switch_num_labels (const gswitch *gs)
> vs
> gimple_switch_num_labels (const gimple_switc
Hi,
On Mon, 12 May 2014, Richard Sandiford wrote:
> > Also I'm idly wondering if the explicit sizing of
> > the fields via a bit-field as originally would be better here or just
> > confusing. I guess unsigned and enums are 32bit for all hosts we care
> > about, but if we ever have one where
Hi,
On Sat, 10 May 2014, Richard Sandiford wrote:
> @@ -362,6 +362,9 @@ struct GTY((chain_next ("RTX_NEXT (&%h)"
> /* The INSN_UID of an RTX_INSN-class code. */
> int insn_uid;
>
> +/* The SYMBOL_REF_FLAGS of a SYMBOL_REF. */
> +unsigned int symbol_ref_flags;
> +
In [3/7] y
Hi,
On Sat, 10 May 2014, Mike Stump wrote:
> > The rtx u2 field currently uses a desc/tag pair for GTY. This seems
> > unnecessary though,
>
> > OK to install?
>
> Ick. I don’t favor skip. The change feels like a premature
> optimization that doesn’t net any code gen benefit. I’ll defer to
Hi,
On Fri, 25 Apr 2014, Richard Biener wrote:
> Btw, I agree we should stick to one style throughout the code-base.
> The advantage of the cast variant is that it can be made work with
> NULL pointers (in the dyn_cast <> case).
NULL pointers shouldn't even be casted at all, there should be sens
Hi,
On Thu, 24 Apr 2014, David Malcolm wrote:
> Implicit naming
> ===
> Several people have suggested that the "gimple_" prefix is redundant.
Not generally though (for instance I find it redundant in the
cast-method names, but _not_ in the global types).
> Andrew MacLeod suggested
Hi,
On Thu, 24 Apr 2014, Andrew MacLeod wrote:
> Well, we ought to settle on one... either use the is_a, as_a, and
> dyn_cast paradigm as they exist today, or we use the cast_as_method
> approach everywhere. I'm not fond of each potential project having a
> different approach... I'd like to
Hi,
On Mon, 21 Apr 2014, David Malcolm wrote:
> This is a greatly-expanded version of:
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
>
> As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
> r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
> statements
Hi,
On Fri, 18 Apr 2014, Steven Bosscher wrote:
> IMHO TER should be improved to *do* disturb the order of the incoming
> instructions, to reduce register pressure.
The latter is the goal, yes. But TER isn't really the right place for
that (it's constrained by too many invariants, running afte
Hi,
On Thu, 17 Apr 2014, Richard Biener wrote:
> The patch below increases the number of coalescs we attempt
> to also cover unary and binary operations.
This is not usually a good idea if not mitigated by things like register
pressure measurement and using target properties to determine if it'
Hi,
On Tue, 8 Apr 2014, Hans-Peter Nilsson wrote:
> Also, do we really want to document the trick in
> "m" ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
> (note: reformatted GNU-style and confusing @{ @} dropped)
We already document this since quite some time, and yes, it's indeed
Hi,
On Mon, 24 Mar 2014, Richard Henderson wrote:
> See
>
> http://en.wikipedia.org/wiki/X86_calling_conventions#pascal
>
> Since we don't actually support this anymore, we can certainly tidy this
> up.
Yeah, I thought about that, but I couldn't see how that could have used
PUSH_ARGS_REVER
Hi,
On Mon, 24 Mar 2014, Richard Biener wrote:
> Maybe somebody remembers why we have both paths. I'd rather make
> gimplification independent of this as well, choosing either variant.
I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's
the way that initially was there, be
Hi,
On Wed, 29 Jan 2014, Jakub Jelinek wrote:
> > > It is also problem of inliner quality decisions and memory
> > > use/compile time. The in-memory representation of unnecesary EH is
> > > quite big.
> > >
> > > I am quite ignorant in this area, but for -O0 can't we simply
> > > disable all
Hi,
On Tue, 28 Jan 2014, Jan Hubicka wrote:
> It is also problem of inliner quality decisions and memory use/compile
> time. The in-memory representation of unnecesary EH is quite big.
>
> I am quite ignorant in this area, but for -O0 can't we simply disable
> all clobbers?
That sounds reason
Hi,
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 28, 2014 at 01:48:21PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> >
> > > There are two kinds of clobbers, the direct ones, which surely can be
> &
Hi,
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> There are two kinds of clobbers, the direct ones, which surely can be
> safely removed by ehcleanup1 if they are the only reason why there is a
> landing pad which will be rethrown outside of the current function,
You can only safely (as in, not
Hi,
On Tue, 28 Jan 2014, Richard Biener wrote:
> >> The EH optimizations involving cleanups with only clobbers in them
> >> are that if at the end of the cleanup after only CLOBBER stmts you
> >> would rethrow the exception externally, then the clobber isn't needed
> >> and the whole cleanup c
Hi,
On Wed, 20 Nov 2013, Jeff Law wrote:
> > There are three places the patch doesn't touch:
> >
> > (A) cfgbuild.c (make_edges) has this comment:
> >/* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb
> > block
> > is always the entry. */
> > where the meaning wasn't
Hi,
On Mon, 25 Nov 2013, David Malcolm wrote:
> I'm not a fan of these "_layout" names, but I'm not sure what better to
> call them. Perhaps:
>GSS_OMP_PARALLEL_LAYOUT -> GSS_OMP_WITH_CLAUSES_CHILD_FN_DATA_ARG
>GSS_OMP_SINGLE_LAYOUT -> GSS_OMP_WITH_CLAUSES
>GSS_OMP_ATOMIC_STO
Hi,
On Fri, 22 Nov 2013, Xinliang David Li wrote:
> > Apart from the issue that LTO drops all BLOCKs this makes the middle-end
> > feature too much tied to the C family frontends and their definition
> > of restrict. It also requires BLOCK lookup / matching at the time
> > of the alias query (wh
Hello,
after much pondering about the issue we came up with this design to
handle restrict more generally. Without a completely different way of
representing conflicts (or non-conflicts) of memory references we're bound
to somehow encode the necessary information into the points-to set (or in
Hi,
On Tue, 19 Nov 2013, Richard Biener wrote:
> $subject - the following turns
>
> loop_iterator li;
> FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
>{
> ...
> if ()
>FOR_EACH_LOOP_BREAK;
>}
>
> into
>
> FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
>{
> ...
>
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> > I think if following through with the whole plan there would (and
> > should) be nothing remaining that could be called a gimple expression.
>
> very possibly, i just haven't gotten to those parts yet. I can change
> the name back to gimple-de
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> > That's why I think talking about a gimple expression as if they were
> > somehow some stand-alone concept is fairly confusing, and introducing it
> > now as if it would somewhen exist would lead to going down some inferior
> > design paths.
>
>
Hi,
On Thu, 14 Nov 2013, Richard Biener wrote:
> Why not give bitmap_head a constructor/destructor and allow auto use of
> that. Isn't that exactly what should get 'auto' handling automagically?
auto != c++98 :-/
Ciao,
Michael.
Hi,
On Wed, 13 Nov 2013, Andrew MacLeod wrote:
> There needs to be a place which has gimple componentry that is not
> related to or require a statement. gimple.h is becoming the home for
> just 0gimple statements. There are 3 (for the moment) major classes of
> things that are in statements
Hi,
On Thu, 14 Nov 2013, Jeff Law wrote:
> Thanks. It's pretty much what I expected. Obviously for other codes
> there may be a lot more changes that you have to slog through, but I
> think this example shows the main concepts.
>
> Presumably in this new world order, the various gimple state
Hi,
On Wed, 13 Nov 2013, Joseph S. Myers wrote:
> +In GNU C, but not GNU C++, you may also declare the type of a variable
> +as @code{__auto_type}. In that case, the declaration must declare
> +only one variable,
What's the reason for this restriction? I can't see what would become
ambiguous
Hi,
On Thu, 7 Nov 2013, Alec Teal wrote:
> > > subclass, by adding empty subclasses derived from the GSS_-based
> > > subclasses as appropriate (I don't bother for gimple codes that already
> > > have their own subclass due to having their own GSS layout). I also
> > > copied the comments from g
Hi,
On Wed, 6 Nov 2013, David Malcolm wrote:
> > I don't like that. The empty classes are just useless, they imply a
> > structure that isn't really there, some of the separate gimple codes
> > are basically selectors of specific subtypes of a generic concept,
> > without additional data or m
Hi,
On Wed, 6 Nov 2013, Ilya Enkovich wrote:
> >>> Well, but clearly you can see that bounds for p == NULL are
> >>> useless and thus there is no problem with the transform.
> >>
> >> This example just demonstrates the issue. I may use some var's address
> >> in comparison with the similar result
Hi,
On Tue, 5 Nov 2013, David Malcolm wrote:
> Here's a followup patch which ensures that every gimple code has its own
> subclass, by adding empty subclasses derived from the GSS_-based
> subclasses as appropriate (I don't bother for gimple codes that already
> have their own subclass due to hav
Hi,
I just hit this problem where gengtype thought an existing gt-*.h header
was the same as what it wanted to write because its prefix was indeed
equal to the buffer, but contained some additional things afterwards.
gengtype simply forgot to check that the file end is reached at buffer
end.
Hi,
On Tue, 15 Oct 2013, Richard Biener wrote:
> On Sun, Oct 6, 2013 at 2:22 PM, Bernd Edlinger
> wrote:
> > How I should proceed with this patch, is it OK?
> >
> > The latest version was posted at:
> > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html
>
> I have now attached a quick dra
Hi,
On Mon, 30 Sep 2013, Jeff Law wrote:
> > - the compiler better do an awesome job of sharing stack space for
> > user variables in a function... I wouldn't want to blow up the stack
> > with a bazillion unrelatd temps each wit their own location.
> If the objects have the same type and disj
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
> My example in this form would look something like:
> int unsignedsrcp = ptrvar.type().type().type_unsigned();
>
> <...>
> GimpleType t1 = ptrvar.type ();
> GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia already, will you? ;-)
Ciao,
M
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
> > > I was going to bring it up at some point too. My preference is
> > > strongly to simply eliminate the space on methods...
> > Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
> Yea. I actually reviewed the libstdc++ guide
Hi,
On Fri, 20 Sep 2013, David Malcolm wrote:
> Treat GTY structs that have a "desc" as being the root of an inheritance
> hierarchy. Generate a switch on desc within the marking function with
> cases for each subclass, visiting all fields of the type (including
> inherited ones).
Yay! Thanks
Hi,
On Fri, 20 Sep 2013, Trevor Saunders wrote:
> > > very ugly FWIW. I only added the underscores because that's what
> > > the conventions said.
> > >
> > > But we're never going to get consensus on this kind of thing. E.g.
> > > I know some people really hate the GNU formatting style (alth
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
> > I know, and I don't like it there either.
>
> Well, as Ian pointed out, it is in our recommended style guidelines and
> you'll find uses in the vec class as well.
As I said, yes; I also said those were pre-existing from the C times
already, so they
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
> On 09/18/2013 10:24 AM, Michael Matz wrote:
> >
> > I'm irritated by the member name uglification (e.g. equiv_stack_ with
> > trailing underscore). I know that's a certain style to mark private
> > members, but I t
Hello,
On Tue, 17 Sep 2013, Jeff Law wrote:
> I put the attached patch through a bootstrap and regression test cycle on
> x86_64-unknown-linux-gnu. As expected no regressions. Installed onto the
> trunk.
>
> Thanks Trevor!
You missed one comment style nit, and some ChangeLog entry nits.
I'm
Hi,
On Wed, 18 Sep 2013, Zhenqiang Chen wrote:
> The patch is updated according to your comments. It is a basic support,
> which does not touch ifcombine and jump related optimizations yet.
>
> Current method is:
> 1) In fold-const, if HAVE_conditional_compare, set
> LOGICAL_OP_NON_SHORT_CIRCUIT
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> > Why do you think so? The t-* frags are includes via
> > ...
> > tmake_file=...$(srcdir)/config/i386/t-i386
> > ...
> > ifneq ($(tmake_file),)
> > include $(tmake_file)
> > endif
> > ...
> >
> > It's just that there's no t-alpha frag yet.
>
> No, t
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> >> Where? I don't see config/alpha.c listed anywhere.
> >
> > Must be in one of the fragments in config/ or config/alpha. For
> > i386 it's config/i386/t-i386
>
> Well, we have a problem here. The dependencies from t-* files are
> ignored
Why do yo
Hi,
On Thu, 5 Sep 2013, Andrew MacLeod wrote:
> 1 - I think we ought to split out the data structures from gimple.h into
> gimple-core.h, like we did with tree.h
Why?
> gimple.h. That won't really affect my work. I think it probably ought to be
> done for clarity eventually.gimple.h wou
Hi,
On Thu, 5 Sep 2013, Richard Biener wrote:
> > (1) whether it's OK for wide_ints to be writable.
> >
> > The interface already exposed the idea of an array of blocks,
> > via get_val() and get_len(). The question here is whether it is OK
> > to also have the corresponding write f
Hi,
On Tue, 3 Sep 2013, David Malcolm wrote:
> > I can't really say I find this shorter, easier to read, more
> > expressive or even safer than what was there before. And the
> > repetition for adding the helpers for const and non-const types
> > all the time doesn't make it bet
Hi,
On Fri, 30 Aug 2013, David Malcolm wrote:
> Here's the result of a pair of builds of r202029 without and with the
> patches, configured with --enable-checking=release, running "make", then
> stripping debuginfo [1]
>
> So the overall sizes of such binaries are essentially unchanged.
Yep, co
Hi,
On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>
> >> I thought the principle that was acquired was that gengtype shouldn't
> >> be improved to support more than what it does now….
> >
> > If it means that we'll need to write and maintai
Hi,
On Thu, 29 Aug 2013, David Malcolm wrote:
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I'd like to see some statistics for cc1{,plus} codesize and for compile
time of something reason
Hi,
On Thu, 29 Aug 2013, Richard Biener wrote:
> > Fork-fire-forget is really a much simpler choice here IMO; no worries
> > about shared resources, less debug hassle.
>
> It might be not as cheap as it is on Linux hosts on other hosts of
> course.
Sure. Don't use it there then. Not a reason
Hi,
On Wed, 21 Aug 2013, Richard Biener wrote:
> I also fail to see why threads should not work here. Maybe simply
> annotate gcc with openmp?
Threads simply don't work here, because the whole streamer infrastructure
(or anything else in GCC for that matter) isn't thread safe (you'd have to
Hi,
On Fri, 12 Jul 2013, Ian Lance Taylor wrote:
> >> It was probably a mistake to have a linker -O option at all.
> >
> >
> > Doesn't the linker produce something that is faster to link and/or smaller,
> > with this flag?
>
> For gold I think it has two effects. If you use compressed debug
> s
Hi,
On Fri, 12 Jul 2013, Marc Glisse wrote:
> If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED
> (for LONG_MIN)?
Right, ...
> FLOAT_TYPE_P does seem safer indeed.
... hence this is it now.
>
> I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing
Hi,
On Fri, 12 Jul 2013, Michael Matz wrote:
> Hi,
>
> GCC happily transforms (float)-z into -(float)z, even when z is of
> unsigned type (when it's larger than float). That's wrong (the result
> should always be positive, because -z is). It seems to me that
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably recent GCC versions. The checking in
convert_to_real
On Wed, 19 Jun 2013, Joern Rennecke wrote:
> > I.e. the arguments after your patch are exactly swapped. This is usually
> > harmless, but not always, so that should be corrected before check in.
> > The change in cselib.c:cselib_invalidate_mem has the same problem.
>
> Well, I have already commi
On Sun, 16 Jun 2013, Joern Rennecke wrote:
> Quoting Eric Botcazou :
>
> > Could you also check that your patch also fixes PR opt/57569 and, if so, add
> > the reference to the ChangeLog as well as the testcase?
>
> Attached is what I'm currently testing. bootstrap on i686-pc-linux-gnu
> finishe
Hi,
On Tue, 14 May 2013, Uros Bizjak wrote:
> I'd propose to introduce:
>
> a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
>
> b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS
This would break -m32.
> c) #undef and #define DEFAULT_TLS_SEG_REG in rdos.h to SEG_GS
>
> Then u
Hi,
On Wed, 13 Mar 2013, Diego Novillo wrote:
> To use the builder:
>
> 1- Declare an instance 'gb' of gimple_builder_normal or
>gimple_builder_ssa. E.g., gimple_builder_ssa gb;
>
> 2- Use gb.add_* to add a new statement to it. This
>returns an SSA name or VAR_DECL with the value of t
Hi,
On Thu, 14 Mar 2013, Richard Biener wrote:
> That said - can we please pass in the type of the operation (and thus
> the newly created result temporary) _explicitely_ please? Thus
I'm mostly with you (not adding gimple_builder_ssa, but improving the
existing interface), except for this on
Hi,
On Tue, 5 Mar 2013, Richard Biener wrote:
> > I haven't tested this patch at all, except making sure that it
> > compiles. Just posting this for discussion, and for feedback on the
> > idea. I know there have been many others before me who've tried
> > different data structures for bitmaps
Hi,
from IRC:
"[15:45:21] ick - lookup_constraint for multi-letter constraints
is quite expensive ... strncmp is not expanded inline for some reason"
Instead of fiddling with strncmp inlining, simply generate better code
from the start for two character constraints:
switch (str[0]) {
ca
Hi,
On Wed, 6 Feb 2013, Richard Biener wrote:
> realloc can also effectively free memory. But the above no longer
> considers free () a freeing call as well?!
free is not ECF_LEAF, so is handled correctly, like tm_free. I didn't
consider realloc, it's indeed not handled.
> That said, please
Hi,
On Wed, 6 Feb 2013, Jakub Jelinek wrote:
> First of all, I'd use gimple_call_builtin_p (call, BUILT_IN_NORMAL)
> test. And, the function should certainly conservatively return false
> for all builtins that aren't (gimple_call_flags (call) & ECF_LEAF) != 0,
> otherwise they might call hook
Hi,
marking of non-trapping accesses currently has an issue when there's a
call between the dominated and the dominating access (that makes the
former non-trapping), namely when that call frees the accessed memory (or
makes it unavailable via other means).
Instead of a full-blown algorithm ite
Hi,
On Wed, 30 Jan 2013, Richard Biener wrote:
> 483 {
> 484 redirect_immediate_dominators (CDI_DOMINATORS, bb, new_bb);
> 485 set_immediate_dominator (CDI_DOMINATORS, new_bb, bb);
> 486 }
>
> but that doesn't set dominance info to DOM_OK again. The
> iterate
Hi,
On Mon, 28 Jan 2013, Richard Biener wrote:
> What's the point of switching to the outermost scope for unknown-BLOCK
> locations?
It's the most sensical block for code which isn't otherwise associated
with a BLOCK. But the latter Shouldn't Happen, because conceptually all
code runs in some
Hi,
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > Going over this what's strange as well is that we adjust MEM_SIZE
> > with bitpos, too. At least when the MEM has non-BLKmode this
> > means that MEMs mode and MEM_SIZE is inconsistent? Or how do
> > a MEMs mode and MEM_SIZE relate?
>
> Yes, th
Hi,
On Fri, 7 Dec 2012, Jan Hubicka wrote:
> > > Actually the calculix regression is also seen on core.
> > > Igor was looking into what loops got slower and why. Either we can fix
> > > that partiuclar
> > > loop or revert to the old default (that sadly causes quite a lot of code
> > > bloat)
Hi,
On Tue, 20 Nov 2012, Martin Jambor wrote:
> > +++ gcc/ipa-cp.c2009-09-29 15:29:05.0 +0200
> > @@ -298,7 +298,7 @@ ipcp_lattice_from_jfunc (struct ipa_node
> > return;
> >cst = caller_lat->constant;
> >
> > - if (jfunc->value.pass_through.operation != NOP_EXPR)
>
Hi,
On Mon, 19 Nov 2012, Steven Bosscher wrote:
> On Mon, Nov 19, 2012 at 2:10 PM, Michael Matz wrote:
> > Hi,
> >
> > On Fri, 16 Nov 2012, Andrew Pinski wrote:
> >
> >> >> Ah, yes. This one was amusing. When we were drafting the proposal,
> >
Hi,
On Fri, 16 Nov 2012, Andrew Pinski wrote:
> >> Ah, yes. This one was amusing. When we were drafting the proposal,
> >> Lawrence kept wondering what this NOP_EXPR thing is. I've been
> >> suffering this name for so long, that it no longer irritates me.
> >> Had it been named CAST_EXPR,
Hi,
On Thu, 15 Nov 2012, Steven Bosscher wrote:
> > Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> > being built. Attached patch fixes this.
>
> Eh???
Uhh???
> Isn't C++ always built, because gcc itself requires it?
Without bootstrapping it doesn't, no.
Ciao,
Michael
Hi,
On Tue, 30 Oct 2012, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 3:17 PM, Dehao Chen wrote:
> >> And tree expressions don't have TREE_BLOCK before gimple-low either.
> >> So IMNSHO it is gimple-low.c that should set TREE_BLOCK of all the gimple
> >> stmts as well as all expression in the
Hi,
On Mon, 29 Oct 2012, Dehao Chen wrote:
> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 29 Oct 2012, Richard Biener wrote:
> >
> >> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
> >> >
Hi,
On Mon, 29 Oct 2012, Richard Biener wrote:
> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
> > because you unconditionally overwrite TREE_BLOCK of all operands (and all
> > operands operands) with the statements block. I assume the unit-test you
> > added shows the pr
Hi,
On Fri, 26 Oct 2012, Dehao Chen wrote:
> 1. abandon the changes in cfgexpand.c
Well, you merely moved the bogus code to gimple-low.c. It is bogus
because you unconditionally overwrite TREE_BLOCK of all operands (and all
operands operands) with the statements block. I assume the unit-test
Hi,
On Thu, 25 Oct 2012, Dehao Chen wrote:
> >> * cfgexpand.c (set_expr_location_r): New callback function.
> >> (gimple_assign_rhs_to_tree): Walk the expr recursively.
> >> (expand_call_stmt): Likewise.
> >> (expand_gimple_stmt_1): Likewise.
> >
> > This cannot be right. You're going to propaga
Hi,
On Tue, 23 Oct 2012, Richard Biener wrote:
> > So, one question, are you claiming that a VRP worker like this:
> >
> >VR derive_new_range_from_operation (VR a, VR b)
> >
> > is _ever_ allowed to return UNDEFINED when a or b is something else than
> > UNDEFINED? You seem to claim so AF
Hi,
On Tue, 23 Oct 2012, Richard Biener wrote:
> > > > ... for this. We should never "produce" UNDEFINED when the input
> > > > wasn't
> > > > UNDEFINED already.
> > >
> > > Why?
> >
> > Because doing so _always_ means an invalid lattice transition. UNDEFINED
> > is TOP, anything not UNDEF
Hi,
On Mon, 22 Oct 2012, Richard Biener wrote:
> On Mon, 22 Oct 2012, Michael Matz wrote:
>
> > Hi,
> >
> > On Mon, 22 Oct 2012, Richard Biener wrote:
> >
> > >
> > > This fixes PR55011, it seems nothing checks for invalid lattice
> > &g
Hi,
On Mon, 22 Oct 2012, Richard Biener wrote:
>
> This fixes PR55011, it seems nothing checks for invalid lattice
> transitions in VRP,
That makes sense, because the individual parts of VRP that produce new
ranges are supposed to not generate invalid transitions. So if anything
such checkin
401 - 500 of 848 matches
Mail list logo
