This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR63259: bswap not recognized when finishing with rotation


On Wed, Oct 8, 2014 at 9:04 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Oct 08, 2014 at 02:56:46PM +0800, Thomas Preud'homme wrote:
>> > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
>> > owner@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>> > Sent: Wednesday, October 08, 2014 2:43 PM
>> > > Also, perhaps you could short-circuit this if the rotation isn't by constant
>>
>> Note that do_shift_rotate already check for this. Is it enough?
>
> The question is only about the compile time cost needed through all the
> routines find_bswap_or_nop calls before it finds out it can't do anything
> with the rotate, the short-circuiting could avoid that.  E.g.
> find_bswap_or_nop_1 first recurses on the argument etc.

I wouldn't worry about that too much.  Indeed the question would be what
should be canonical on GIMPLE (expanders should choose the optimal
vairant from both).  I think a tree code should be always prefered to a
builtin function call - which means a rotate is more canonical than a
bswap16 call.

>From the performance side the pass could be re-structured to populate
a lattice, thus work from def to use instead of the other way around.  Which
means we visit each stmt exactly once, compute its value symbolically
and check it against a rotate.

Richard.

>         Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]