On Wed, Jul 22, 2015 at 2:40 AM, Andrew Pinski <andrew.pin...@caviumnetworks.com> 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.
Canonical GIMPLE is what has less GIMPLE operations. In this case it's a << N ==/!= 0 (two ops), not a & (-1 >> N) ==/!= 0 (three ops). Thus on GIMPLE the transform is not wanted. Richard. > Thanks, > Andrew > >> >> Richard. >> >>> Jakub >> >>
