similar to: [LLVMdev] post-inc loads/stores

Hi Jonas, There's not really a very clean way to do this currently. The ARM backend does it as you indicate with the writeback register listed as an output as well as an input and marked as a tied operand constraint. Search for _PRE and _POST in ARMInstrInfo.td for examples. For most instances, instruction selection is done via custom lowering, not an ISel pattern on the pattern; see

When I compile the following program (for ARM): for(i=0;i<n2;i+=n3) { s+=a[i]; } , with GCC, I get the following loop body, with a post-modify load: .L4: add r1, r1, r3 ldr r4, [ip], r6 rsb r5, r3, r1 cmp r2, r5 add r0, r0, r4 bgt .L4 With LLVM, however, I get: .LBB0_3: @

On Jan 27, 2011, at 11:13 PM, Jonas Paulsson wrote: > Hi, > > I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this > is exactly what I

Hi, I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this is exactly what I would like to handle: a simple loop with an address that is inremented in

Hi Evan, Thanks for the answers. I had few more queries though. 1. As far as I was able to understand the Codegen infrastructure, ARMInstrInfo.td file has complete description of the instructions which modify the status flags. For example, we have description for both ADD and ADDS. But the problem is that in LLVM, we have a single "ADD" Instruction. Thus when we do getDesc(add), we get

On Sun, Dec 18, 2016 at 11:58 PM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > > Actually, there's another —even more fundamental— problem: the longjmp > will always restore the non-volatile registers to the contents they had > at the start of the try-block, which is not what LLVM expects when > entering an SEH-based landing pad. > The SjLjEHPrepare pass tries

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

Jonas Maebe via llvm-dev wrote: > Then, I tried the following: > a) if the longjmp for the try-block is taken (i.e., the setjmp right > before the try-block returns a non-zero value), jump to the landingpad BBL. > > -> Problem: LLVM does not allow regular jump edges to landingpad BBLs > > b) since the landingpad is empty anyway and falls through into the next > BBL

On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote: > Recap: we use setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

You probably meant to send this to LLVMdev as well. Begin forwarded message: Date: Mon, 29 Nov 2010 08:26:03 +0100 From: Jonas Paulsson <jnspaulsson at hotmail.com> To: <edwintorok at gmail.com> Subject: RE: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41 Yes, the new type is simply a static object managed by Type and LLVMContext. This is only referred to by Values of fixed point type.

I have been struggling with this for way too long now, so hopefully the mighty list can help: I am trying to generate a byte store instruction storing the constant value 4 at some given address in a new helper function inside ARMISelLowering.cpp I tried: SDValue Val = DAG.getConstant(4, MVT::i8); SDValue Store = DAG.getStore(chain, dl,

On Jul 14, 2008, at 5:10 PM, kapil anand wrote: > Hi Evan, > > Thanks for the answers. I had few more queries though. > > 1. As far as I was able to understand the Codegen infrastructure, > ARMInstrInfo.td file has complete description of the instructions > which modify the status flags. For example, we have description for > both ADD and ADDS. But the problem is

<retitling to be useful> LLVM shouldn't have a fixed point type class. You should just use standard integer types. Supporting fixed point and saturation should by done by adding new operations to llvm IR. If you're interested in this, I'd suggest starting by implementing these as intrinsics. If it makes sense over time we can change them to primitive instructions if there is

Hi, is it possible to reduce link time by excluding unused target backends? I would like to type tools/llc make -target=... , and just build it for one backend. /Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110311/c2179915/attachment.html>

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

On Jul 14, 2008, at 12:59 PM, kapil anand wrote: > Hi all, > > I am using LLVM compiler and CodeGen for generating ARM binaries. > > I was going through the code for ARM backend. I noticed that the ARM > Condition field( Bits 31-28) is generated by converting the > conditions used in icmp and branch. For example, if I have following > C Code > > int a,b,c,d;

> > I assume you put your VLIW scheduler before the register allocator super-pass? right > > /jakob > >