https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
alalaw01 at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alalaw01 at gcc dot gnu.org
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #2)
>
> Or do we want to do the transformation always, and maybe have something
> later (in RTL?) to undo it if it didn't help?
>
> Note that in some experiments with more meat in the loop, having
> i<min(n1,n2) made the compiler not see a dominating i<n1 anymore and it lost
> some optimizations.
Can you give an example where it not only doesn't help, but actually hurts? Are
they all just because of not seeing analysis properties, i.e. we could get
there by realizing a<=min(a,...) and looking far enough to see a<X<=Y means a<Y
? In terms of code generation,
t = min (a,b)
if (x<t) goto ...
can always be implemented as
t = a
if (a<b) goto lab
t=b
lab: if (x<t) goto ...
vs
if (x<a) goto ...
if (x<b) goto ...
i.e. the same number of compares and branches, so is it the extra two moves we
are concerned about?
(Jump-threading on RTL to remove even those, perhaps?!)
