This is the mail archive of the
mailing list for the GCC project.
Re: Loop invariant motion from cold block
- From: Pat Haugen <pthaugen at linux dot vnet dot ibm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 06 Nov 2014 14:36:19 -0600
- Subject: Re: Loop invariant motion from cold block
- Authentication-results: sourceware.org; auth=none
- References: <545BB91B dot 9090001 at linux dot vnet dot ibm dot com> <CAFiYyc0U94tTHYZzGVUDdd1gfhRNMkTCEh6wFn2imN2XQ=uwoQ at mail dot gmail dot com>
On 11/06/2014 01:00 PM, Richard Biener wrote:
Yes, that would seem to be the best general approach. My initial hack
was done wrt to example given and apparently I just kept my tunnel
vision goggles on.
Shouldn't we never hoist anything from a bb with lower execution frequency
to a bb with higher one? It seems LIM simply assumes that inside a loop
is always higher frequency than outside of it.
So - why artificially have that factor of 0.1 instead of simply checking for
Good point, and probably the approach that should really be taken in
Btw, we also hoist through multiple loop nests so even an unlikely
branch in the innermost loop may execute more times than the outermost
loop entry. So I believe the change has to be made somewhere else,
like in invariantness_dom_walker::before_dom_children.
Btw, for your example with calling a noreturn function in the loop exit
destination the block containing the k/5 shouldn't be in the loop at all.
I wonder why they are not using __attribute__((noreturn)) in which case
they'd even get better profiles can can get rid of the __builtin_expect?