On Sun, 11 Dec 2011, Andrew Pinski wrote:
> On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay <a...@gjlay.de> wrote:
> > If there was a canonical representation of these operations, a backend
> > wouldn't even notice if the tree passes chose a different, more convenient
> > canonicalization.
>
> The problem is not just the canonicalization but rather there is a
> problem of deciding which regression is important and how to fix it.
There *is* a canonical RTL expression: "Equality comparisons of
a group of bits (usually a single bit) with zero will be written
using @code{zero_extract} rather than the equivalent @code{and}
or @code{sign_extract} operations." See e.g. cris.md "*btst" or
m68k.md (the last two zero_extract after "Recognizers for btst
instructions"; lots of variants there which could be reduced
to two using the "enabled" attribute AFAICT).
> Fixing this regression was easy as it just meant to turn back on the
> optimization that was there already. So after fixing this regression,
> we have another regression with the AVR back-end. I bet the best way
> to fix this is to ask the back-end what is the cost of doing a shift
> and if it is greater than doing an and with a setcc, then we should do
> the and/setcc rather than a shift with the and. It is not hard to add
> a target hook for this case, I can do it if the AVR folks think it
> would be useful.
If tree -> rtl doesn't emit or at least try the canonical RTL
first, then that's the problem.
brgds, H-P
