search for: bswapped

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 Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using the bswap instruction because...

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

...Kanthak <stefan.kanthak at nexgo.de> wrote: > "Craig Topper" <craig.topper at gmail.com> wrote: > > > bswapdi2 for i386 is correct > > OUCH! > > > Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into > > eax. Those are each bswapped. > > This exchanges the high byte of each 32-bit PART with its low byte, but > NOT the high byte of the whole 64-bit operand with its low byte! > > Please get a clue! > > > The ABI for the return is edx contains bits [63:32] and eax contains > > [31:0]. This is opposit...

>> 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

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 <

Hello List, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

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 of invalid patterns as well as

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

Hi! Anyone else experiencing performance problems when using the new monorepo? My experience is that performance of gitk (and git log) sometimes is really bad when working in the monorepo. I've mainly seen it when using gitk on specific files/directories, but since gitk seems to be using "git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- <file>" it

On 10/03/2011 09:36 PM, Villmow, Micah wrote: > One of the projects I am working on with others is to make LLVM-IR endian agnostic. > > > > So, I am sending out this proposal for feedback to the LLVM community. I’ve attached > > pretty version of the proposal in PDF format and pasted a 80-column safe text version > > below. > > > > A second smaller

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,

Developers, As part of PR411, I have made several of the intrinsic functions non- overloaded. While the assembler and bytecode reader are backwards compatible, front-end writers should start using 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

PV-GRUB: xfs support i386 doesn''t have PAE anyway. Index: fsys_xfs.c =================================================================== RCS file: /sources/grub/grub/stage2/fsys_xfs.c,v retrieving revision 1.5 diff -u -p -r1.5 fsys_xfs.c --- fsys_xfs.c 8 May 2005 02:18:14 -0000 1.5 +++ fsys_xfs.c 10 Jul 2008 13:09:50 -0000 @@ -101,7 +101,7 @@ static inline __const__ xfs_uint16_t le16

Have you looked at these? https://llvm.org/docs/LangRef.html https://llvm.org/docs/ExtendingLLVM.html On Tue, Mar 26, 2019 at 9:06 AM div code via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Of course, in this sense they are not platform-dependent. I just want to > write a semantics-correct version of such intrinsics and let my static > analyzer goes smoothly. > > On

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 hacks to

Hi, I'm trying to optimize a pattern like this into a single i16 load: %1 = bitcast i16* %pData to i8* %2 = load i8, i8* %1, align 1 %3 = zext i8 %2 to i16 %4 = shl nuw i16 %3, 8 %5 = getelementptr inbounds i8, i8* %1, i16 1 %6 = load i8, i8* %5, align 1 %7 = zext i8 %6 to i16 %8 = shl nuw nsw i16 %7, 0 %9 = or i16 %8, %4 I came across load combine pass which is motivated

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other

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