--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-06 22:51 ---
Sure. There's this other problem of testsuite regressions you'll get. I've
been
there, it takes a _lot_ of time to do even minimal pass re-ordering / removing
:(
The best strathegy was always to fix deficiencies i
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-06 22:43 ---
Then they should be grouped. And kept grouped.
Here's one case where there has to be a trade-off between micro-optimizations
for specific cases, and compile time for everyone. Please, for once, let us
seriously cons
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-06 22:29 ---
Only they all run at different times during the pass pipeline ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 21:41 ---
We have a new candidate: bswap optimization.
Diego's idea to do "a single scan that calls back to all these transformations
on every statement" really still sounds like The Right Thing to do.
--
steven at gcc dot
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2007-06-19
05:09 ---
Subject: Re: tree-ssa-math-opts.c performs too
many IL scans
> We have reciprocal pass (in fact CSE recip pass) that CSEs 1.0/z from x/z,
> y/z,
> .../z. This is done by scanning function for RDIV_EXP
--- Comment #3 from ubizjak at gmail dot com 2007-06-18 17:40 ---
(In reply to comment #2)
> We need a better explanation than this. Uros agreed to summarize the
> IRC discussion to close this issue. It'd be useful if we keep that same
> discussion on the source code itself.
The need
--- Comment #2 from dnovillo at google dot com 2007-06-18 14:00 ---
Subject: Re: tree-ssa-math-opts.c performs too
many IL scans
On 6/18/07 9:56 AM, rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56
> ---
> All three
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 ---
All three transformations are done at different stages of the optimization
pipeline due to various reasons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
