similar to: [LLVMdev] Prevent a intrinsic to be reordered?

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call,

Hello, Julio > These later things are ignored, I don't know if when the intrinsic is > lowered, then it doesn't matter (or perhaps the reorder is made > before). What is the description of the instruction you're lowering intrinsic into? Have you looked for the instruction flags defined in Target.td file? You instruction should definitely have "isBarrier" flag set.

Hi, I meet an issue when I verify machineinstrs for Powerpc testcases in llvm. llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! *** function: main basic block: %bb.2 for.body.lr.ph (0x100275437e8) Content in block BB.2:

Hello all, I want to add a custom intrinsic to the LLVM IR which would be lowered into a pseudo instruction since it doesn't correspond to any real instruction defined by the architecture. The speciality of this intrinsic/pseudo instruction that it should behave like a scheduling barrier: every instruction before the intrinsic has to be emitted before the intrinsic, the same goes for all

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

I am working on a back end for an architecture whose jump via table instruction includes the range check. If the index is out of range, the jump table instruction just falls through. I implemented a pass to remove the range check generated before the jump table instruction because it is superfluous. This causes as assertion in MachineBlockPlacement.cpp:

Hi Yang, > bnz R2, LBB0_34 > > I do not have any clue what happens when compiling with -O2. > Can someone make a suggestion? Is the "bnz" instruction marked "isBarrier" in your TableGen files? If so, that would mean LLVM considers fallthrough impossible and decides it can move LBB0_33 around at will. It's still very odd that it thinks it can put it

The Sparc, Microblaze, and Mips code generators implement branch delay slots. They all seem to exhibit the same bug, which is not surprising since the code is very similar. If I compile code with this snippit: while (n--) *s++ = (char) c; I get this (for the Microblaze): swi r19, r1, 0 add r3, r0, r0 cmp r3, r3, r7 beqid r3,

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

On Tue, 9 Jan 2007, Evan Cheng wrote: >> - How does one deal with multiple instruction sequences in a pattern? >> To load a constant is a two instruction sequence, but both >> instructions only take two operands (assume that r3 is a 32-bit >> register): >> >> ilhu $3, 45 # r3 = (45 << 16) >> iohl $3, 5 # r3 |= 5

Hi, I've been experimenting with writing a backend for LLVM (3.2) (having already written a frontend http://savourysnax.github.com/EDL), everything was going reasonably ok ( calls/returns, epilogue, prologue, etc are all working), up until I tried to place support for conditional branches. Given this simple program : int test(int c,int d) { if (c) { return

On Jan 9, 2007, at 5:23 PM, Scott Michel wrote: > Chris Lattner wrote: >>> It is possible to write multi-instruction pattern, e.g. >>> X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? >>> Sounds like you want to define them as SDNodeXform that returns >>> upper >>> and lower 16 bits respectively. Take a look at PSxLDQ_imm in

Setting the MI as isTerminator should have the same impact, yes? I'm not sure of the other consequences of this though, if any, have to look into it. Thanks. -Ryan On Tue, Nov 15, 2016 at 5:18 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > You can override TargetInstrInfo::isSchedulingBoundary for that. > > -Krzysztof > > On 11/15/2016 4:13 PM, Ryan

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Chris Lattner wrote: >>It is possible to write multi-instruction pattern, e.g. >>X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? >>Sounds like you want to define them as SDNodeXform that returns upper >>and lower 16 bits respectively. Take a look at PSxLDQ_imm in >>X86InstrSSE.td as an example. > > > Another good example is the PPC

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

Okay so i implemented an(other :) initial version for X86-32 backend, this time based on TOT: It is not very generic at the moment. Only functions with callingconv::fastcc and the tail call attribute will be optimized. Maybe the next step should be to integrate the code into the other calling convention lowering. Here is what i have at the moment: If callingconv::fastcc is used the

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

Hi, I'm writting an intrinsics for the X86 plateform that replace every 'call' instruction by a 'push ret_addr' followed by a 'jmp func_addr'. I'm doing this in the X86ISelLowering class with a custom inserter. So if I have something like this: 0x0 call foobar 0x1 ... the call will be replaced like this: 0x0 push 0x2 0x1 jmp foobar_addr 0x2 ... This works fine

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >