On 07/21/2015 06:40 PM, Andrew Pinski wrote:
On Tue, Jul 21, 2015 at 12:16 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
On July 21, 2015 11:38:31 AM GMT+02:00, Jakub Jelinek <ja...@redhat.com> wrote:
On Tue, Jul 21, 2015 at 09:15:31AM +0000, Hurugalawadi, Naveen wrote:
Please find attached the patch which performs following patterns
folding
in match.pd:-
a ==/!= a p+ b to b ==/!= 0.
a << N ==/!= 0 to a&(-1>>N) ==/!= 0.
Not sure about this second one. Why do you think it is generally
beneficial? On many targets, shifts are as fast as bitwise and, and
-1>>N could be e.g. significantly more expensive constant (say require
3 instructions to construct).
And may set flags while shift not? Of course we do a very poor job of
representing this kind of stuff on gimple.
The biggest question now becomes which way is the canonical form for
gimple and we can decide to optimize it on the RTL level (combine)
instead if it produces better code in those cases.
Note on AARCH64, producing x&(-1>>N) has no cost difference from a<<N
so we would like to do it there. Also in this case producing flags is
useful.
Funny I was having a discussion with Kai about this class of problems
yesterday.
It seems to me in these kind of cases that selection of the canonical
form should be driven by factors outside of which is better for a
particular target. ie, which is simpler
Instead we should be looking at the gimple->rtl expansion phase to
expand using a form that is better for a particluar target.
[And yes, I think I've violated this new guiding principle in the past]
Given the (a << n) EQ/NE form, can we reasonably detect this in the
gimple->expansion phase and emit code as if we had the alternate form
for targets such as aarch64?
jeff
