[Bug tree-optimization/26854] Inordinate compile times on large routines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #123 from Daniel Berlin 2011-01-18 14:54:33 UTC --- On Tue, Jan 18, 2011 at 9:49 AM, hubicka at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 > > Jan Hubicka changed: > > What |Removed |Added > > CC| |hubicka at gcc dot gnu.org > > --- Comment #122 from Jan Hubicka 2011-01-18 > 14:48:32 UTC --- > oprofiling shows that 50% of parsing time is in decl_jump_unsafe that is C > frontend thingy to output some sort of warnings on gotos to VLAs. This can > probably be solved quite easilly. > > Later we get (at -O2 all.i) > 83417 17.0179 cc1 dominated_by_p > 75164 15.3342 cc1 bitmap_equal_p > 38134 7.7797 cc1 bitmap_set_bit > 26144 5.3336 cc1 bitmap_ior_into > 21031 4.2905 cc1 decl_jump_unsafe > 16142 3.2931 cc1 register_new_assert_for.isra.42 > 12713 2.5936 cc1 bitmap_elt_insert_after > 11136 2.2719 cc1 sbitmap_a_or_b > 10625 2.1676 cc1 et_splay > 10059 2.0521 cc1 walk_dominator_tree > 6775 1.3822 cc1 dse_enter_block > 5952 1.2143 cc1 bitmap_bit_p This looks suspiciously like it's not using the DFS numbers
[Bug tree-optimization/26854] Inordinate compile times on large routines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #125 from Daniel Berlin 2011-01-18 15:18:25 UTC --- > > --- Comment #124 from Jan Hubicka 2011-01-18 15:15:01 > UTC --- >> >> This looks suspiciously like it's not using the DFS numbers > It seems that they are used, just we do a lot of queries from > register_new_assert_for > according to my ^C GDB profiling. > Interesting, i wonder why et_splay shows up at all then.
[Bug tree-optimization/57972] New: Statement sinking algorithm should just be replaced with GCM algorithm's late scheduler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57972
Bug ID: 57972
Summary: Statement sinking algorithm should just be replaced
with GCM algorithm's late scheduler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dberlin at gcc dot gnu.org
The store sinking algorithm in tree-ssa-sink.c has grown to the point where it
is *almost*, but not exactly, equivalent to the GCM's schedule_late phase
algorithm presented by Cliff Click in PLDI '95
(http://www.cs.washington.edu/education/courses/cse501/06wi/reading/click-pldi95.pdf)
The current algorithm is basically:
For each bb in post-dominator order:
For each statement in reverse:
find sink location using nearest common dominators of users.
compute validity
move to sink location
This requires computing post dominators, among other things.
The GCM algorithm is, basically:
FOr each unmovable instruction I
mark I as pinned
I.visit = true
for each use U of I
schedule_late (U)
For every other instruction I
schedule_late (I)
schedule_late is essentially the same as statement_sink_location + movement,
with the different that it recursively calls itself to on the users to move
them first.
//Find latest legal block for instruction i
Schedule_Late( instruction i ) {
if i.visit = True then
return;
i.visit:= True;
Block lca = empty
forall uses y of i do {
Schedule_Late( y );
Block use := y.block;
if y is a PHI then {
// Reverse dependence edge from i to y
Pick j so that the jth input of y is i
// Use matching block from CFG
use := y.block.CFG_pred[j];
}
lca := Find_LCA( lca, use );
}
// You can place i in lca.
}
This should do slightly better than GCC's algorithm, and not require computing
postdominators explicitly.
The LCA computation performed is equivalent to using nearest_common_dominator.
[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120 --- Comment #8 from Daniel Berlin 2012-03-05 17:20:36 UTC --- I still have an unfinished patch to convert SCCVN to http://dl.acm.org/citation.cfm?id=512536 This actually makes it significantly easier to integrate better congruence finding (and lets us use predicates properly during value numbering). It also was significantly faster in large functions (also functiojns containing large SCC's) due to a significantly better iteration strategy (it will only iterate values that are changing, while SCCVN will iterate all values in an SCC). I'm happy to attach the patch if you like :) On Sat, Mar 3, 2012 at 7:45 PM, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120 > > --- Comment #7 from Andrew Pinski 2012-03-04 > 00:45:50 UTC --- > I might even have a patch for my tree combine branch later today. I still > have > to connect up ssa_combine to SCCVN but that should not be hard. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #17 from Daniel Berlin --- Not sure how i ended up on the CC list for this one, but i actually would disagree it would be better than nothing. Features that can only be made to work a small amount and are incapable of being improved tend to be the ones users complain about the most. In cases where you can't even get to 30% or 40%, let alone 80%, it's often better to do nothing. On Tue, Jul 23, 2019 at 9:20 PM egallager at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 > > --- Comment #16 from Eric Gallager --- > (In reply to Jakub Jelinek from comment #12) > > And then there is the case of endless loops in such functions (either > > unconditional, or ones the compiler is not able to detect), exit calls, both > > either directly in the const/pure function or in some function it calls. So > > in all, I'm afraid such a warning would diagnose only the most trivial > > cases. > > That would still be better than nothing. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #25 from Daniel Berlin --- This seems like a bad idea, and is impossible in general. The whole point of the attributes is to tell the compiler things are pure/const in cases it can't already prove. It can already prove a lot, and doesn't need help in most of the simple examples being given (in other bugs). You are basically going to warn in the cases the compiler can't prove it (IE sees something it thinks makes the function not pure/const), and those are *exactly* the cases the attribute exists for - where the compiler doesn't know, but you do.
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #29 from Daniel Berlin --- Let me try to explain a different way: The only functions GCC can warn about are those that don’t need the attributes in the first place. The way any warning would work is to detect whether it is pure/const, and then see how the user marked it. So anything it can properly detect as right or wrong didn’t need an attribute to begin with - the compiler could already tell if it was pure/const Rather than tell the user they got it wrong, you might as well tell the user to remove the attribute because it isn’t necessary and won’t be necessary. This is precisely why attributes are meant for when you are sure you know more than the compiler can tell, and *no other time *. It is a tool for experts. Giving a bunch of really contrived examples where users may update things wrong doesn’t seem like a good motivation to make a warning that can only possibly have a really high false positive rate. The same logic applies to a lot of expert-use-only attributes. It is assumed you know what you are doing, because the compiler can’t tell you you are wrong accurately On Sat, Sep 4, 2021 at 4:40 PM federico.kircheis at gmail dot com < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 > > --- Comment #28 from Federico Kircheis com> --- > >Edit: sorry, my last comment about what GCC thinks is wrong. > > Unless it is going to inline the function call, in that case the > attributes are > as-if ignored (at least the case I've tested with GCC 11.2). > > -- > You are receiving this mail because: > You are on the CC list for the bug.
