[llvm-dev] BUGS n code generated for target i386 compiling __bswapdi3, and for target x86-64 compiling __bswapsi2()

[Craig Topper via llvm-dev]

In this case there are no truncates. Everything is a 64-bit type. The bswap
pattern is matched by the middle end of the compiler with no target
specific knowledge. The middle end sees the type is 64 bits and so doesn't
match it as bswap because only the lower half is swapped. The X86 specific
backend doesn't do any BSWAP matching so we don't apply the x86 specific
knowledge that zeroing the upper bits is free.


~Craig


On Mon, Nov 26, 2018 at 11:11 AM Fabian Giesen via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 11/26/2018 4:11 AM, Stefan Kanthak via llvm-dev wrote:
> > The other part of my post but holds: the following function, compiled for
> > x86-64, is NOT properly optimized (see <https://godbolt.org/z/uM9nvN>):
> >
> > unsigned long __bswapsi2 (unsigned long ul)
> > {
> >      return (ul >> 3 * 8) & 0xff000000ul
> >           | (ul >>     8) & 0x00ff0000ul
> >           | (ul <<     8) & 0x0000ff00ul
> >           | (ul << 3 * 8) & 0x000000fful;
> > }
>
> That looks like another instance of truncation in the wrong places
> causing the pattern matches to fail. There have been a couple of those
> in the past with other things like rotates.
>
> This is indeed a bug, but if you need a quick workaround, the pattern
> does work when you use a 32-bit (e.g. unsigned int or uint32_t) type.
>
> -Fabian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181126/acc5b884/attachment.html>