search for: bswap

bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Cra...

Hi @ll, targetting i386, LLVM/clang generates wrong code for the following functions: unsigned long __bswapsi2 (unsigned long ul) { return (((ul) & 0xff000000ul) >> 3 * 8) | (((ul) & 0x00ff0000ul) >> 8) | (((ul) & 0x0000ff00ul) << 8) | (((ul) & 0x000000fful) << 3 * 8); } unsigned long long __bswapdi2(unsigned long long ull) {...

I just compiled the two attached files in 32-bit mode and ran it. It printed efcdab8967452301. I verified via objdump that the my_bswap function contains the follow assembly which I believe matches the assembly you linked to on godbolt. _my_bswap: 1f70: 55 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8 bswapl %eax 1f7b: 0f ca bswapl %e...

>> Are you sure there isn't any test coverage? As far as I can tell, the tests from https://reviews.llvm.org/rL133503 are still in the tree. I looked at those, but none of them include the full pattern that decomposes into bswap and rol. I debugged through the X86 bswap.ll test and verified none of those cases make it through MatchBSwapHWord (they get handled in MatchBSwapHWordLow instead). >> I don't think there is any existing code to match this particular pattern in instcombine. I guess it wouldn't be ha...

Hi all, As of r141677 I have a failing regression test, see below. This is for LLVM built with clang on a Intel Atom running FreeBSD8.2. Should I file a bug for this? Thanks, Ed. ******************** TEST 'LLVM :: CodeGen/X86/bswap.ll' FAILED ******************** Script: -- /usr/home/emeewis/build/llvm-debug-clang-configure/Debug+Asserts/bin/llc < /usr/home/emeewis/contrib/llvm/test/CodeGen/X86/bswap.ll -march=x86 | /usr/home/emeewis/build/llvm-debug-clang-configure/Debug+Asserts/bin/FileCheck /usr/home/emeewis/con...

...eration! I tried to do some "delta debugging" and eventually locate the buggy line of the code. So as shown below, the following code cause llc (version 3.8.1) throws the "Unsupported library call operation" issue, but it works fine for llc version 3.9. %20 = call i256 @llvm.bswap.i256(i256 %msg.value) %21 = mul i256 %20, 190 I tried to tweak the buggy lines into the following code, and it can also pass the compilation: %20 = call i256 @llvm.bswap.i256(i256 %msg.value) %21 = add i256 %20, 190 This seems really wired to me.. Any idea on that? Thank you! Best, Iren...

The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConstant(DiffBits, TLI.getShiftAmountTy()))...

I’m looking into problems with the function DAGCombiner::MatchBSwapHWord and had a couple questions on how to proceed (I’m new here, and to llvm). It looks like there was never any test coverage for this code, and it doesn’t match the patterns it claims to be looking for. I found a fix for this in our fork, but the fix is even worse in that it matches a whole bunch...

On 13.10.2011, at 15:57, Edward Meewis wrote: > Hi all, > > As of r141677 I have a failing regression test, see below. > > This is for LLVM built with clang on a Intel Atom running FreeBSD8.2. > > Should I file a bug for this? Fixed in r141863. - Ben

...m/CODE_OWNERS.TXT > /dev/null 55.48user 0.34system 0:55.80elapsed 100%CPU (0avgtext+0avgdata 690124maxresident)k 0inputs+0outputs (0major+174196minor)pagefaults 0swaps bash-4.1$ /usr/bin/time git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- llvm/test/CodeGen/Generic/bswap.ll > /dev/null 192.97user 0.33system 3:13.19elapsed 100%CPU (0avgtext+0avgdata 696496maxresident)k 0inputs+0outputs (0major+176003minor)pagefaults 0swaps Same tests when using the old llvm repo (there is no README.md so I skipped that test here): bash-4.1$ /usr/bin/time git log --no-color -z...

...mory location. Actually I think having the 2 intrinsics you suggest and the is_bigendian() intrinsic would be optimal: you can use your 2 intrinsics for initial codegen, and mem2reg can transform it to is_bigendian(). For load/store: <type> %val = load <type>* %ptr <type> %sval = bswap.i<type> %val %result = <type> select @llvm.is_bigendian(), %val, %sval For htonl(): <type> %sval = bswap.i<type> %val %result = <type> select @llvm.is_bigendian(), %val, %sval (store is similar, byteswap before the store) At bytecode JIT time / assembly emission tim...

On 12/9/2016 11:03 AM, Jim Lewis via llvm-dev wrote: > > Thanks, that helps enormously! The issue is that the match is supposed > to support both cascade and tree OR patterns, but there appears to be > a problem with the tree matching. Both test1 and test6 in the ARM > tests exercise the cascade pattern, and I remember now our fix is > confined to the tree case. > > I

On Dec 22, 2009, at 2:38 PMPST, Bill Wendling wrote: > The LegalizeDAG.cpp file has this code in > SelectionDAGLegalize::PromoteNode: > > case ISD::BSWAP: { > unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); > Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, > DAG.getConstant(DiffBits, &g...

...ing the non-overloaded versions of the intrinsics. The llvm-gcc has already been updated to generate the new intrinsic names. Other front-ends will start seeing warnings about the names of intrinsics that need to be upgraded in the front end. Here are the intrinsics that need to be changed: llvm.bswap -> llvm.bswap.i16, llvm.bswap.i32, llvm.bswap.i64 llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64 llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64 llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64 llvm.isunor...

...t x) { __asm__("xchgb %b0,%h0" \ - : "=q" (x) \ + : "=Q" (x) \ : "0" (x)); \ return x; } @@ -109,9 +109,9 @@ le16 (xfs_uint16_t x) static inline __const__ xfs_uint32_t le32 (xfs_uint32_t x) { -#if 0 +#if 1 /* 386 doesn''t have bswap. */ - __asm__("bswap %0" : "=r" (x) : "0" (x)); + __asm__("bswapl %k0" : "=r" (x) : "0" (x)); #else /* This is slower but this works on all x86 architectures. */ __asm__("xchgb %b0, %h0" \ ________________________________...

...ue, Mar 26, 2019 at 2:03 PM div code <divsubmission at gmail.com> wrote: > >> Hello, >> >> I am basically working on a static analysis project on LLVM IR, and the >> problem is that I will need to simulate the execution of a few LLVM >> Intrinsic, such as llvm.bswap.i160, and llvm.ctlz.i256. >> >> I am wondering if there has been some already implemented sample code, >> regarding these intrinsics? Either C or LLVM IR. Thanks a lot! >> >> Best, >> > _______________________________________________ > LLVM Developers maili...

A rotate intrinsic should be relatively close in cost/complexity to the existing bswap. A grep of intrinsic::bswap says we'd probably add code in: InstCombine InstructionSimplify ConstantFolding DemandedBits ValueTracking VectorUtils SelectionDAGBuilder But I don't think it's fair to view those additions as pure added cost. As an example, consider that we have to add ha...

...acts for the rest of the optimizer. I can't find any backstory for this pass, why was it chosen to optimize the pattern in question in this way? What is the current status of this pass? I have an alternative implementation for it locally. I implemented an instcombine rule similar to recognise bswap/bitreverse idiom. It relies on collectBitParts (Local.cpp) to determine the origin of the bits in a given or value. If all the bits are happen to be loaded from adjacent locations it replaces the or with a single load or a load plus bswap. If the alternative approach sounds reasonable I'll pos...

...>> >> I can't find any backstory for this pass, why was it chosen to optimize the pattern in question in this way? What is the current status of this pass? >> >> I have an alternative implementation for it locally. I implemented an instcombine rule similar to recognise bswap/bitreverse idiom. It relies on collectBitParts (Local.cpp) to determine the origin of the bits in a given or value. If all the bits are happen to be loaded from adjacent locations it replaces the or with a single load or a load plus bswap. >> >> If the alternative approach sounds reaso...

Hello, I am basically working on a static analysis project on LLVM IR, and the problem is that I will need to simulate the execution of a few LLVM Intrinsic, such as llvm.bswap.i160, and llvm.ctlz.i256. I am wondering if there has been some already implemented sample code, regarding these intrinsics? Either C or LLVM IR. Thanks a lot! Best, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attach...