Andrew Pinski schrieb:
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.
Fixing this regression was easy as it just meant to turn back on the
optimization that was there already.
As far as I understand, your patch just undoes some other patch?
So you are playing ping-pong against an other patch that probably tried
to fix similar performance regression on some other target?
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.
I wonder what that new hook would be and why it was needed?
And what information it could provide that is not already available via
rtx costs?
And why the
(set (reg:Amode)
(zero_extract:Amode (reg:Bmode)
(const_int 1)
(const_int bitnumber)))
pattern of your backend does not trigger?
From what you wrote, this is the motivation of your patch?
And this is best represented by a right-shift on ARM, so it could just
be expanded/printed as a right-shift alongside AND 1 as needed?
Johann
Thanks,
Andrew Pinski
