similar to: [LLVMdev] Libcall for double precision comparison.

I have seen that most of the targets do comparison and branching in two separate instructions e.g. 'cmpl' followed by 'br' in x86 or the like. LLVM IR is also in same manner. I want to implement comparison+branching in one instruction like beq r1, r2, .label #if r1==r2 then jump to .label How to merge two instruction into one. Regards Vikram Singh -- View this

Hi, Have you try to directly describe such patterns in tblgen file? Like this: (brcond (i32 (cond_op RC:$rs, RC:$rt)), bb:$offset) MIPS backend does that. I also do this in my own backend, and seem to be working fine. On Mon, Jan 7, 2013 at 11:55 AM, Vikram Singh <vsp1729 at gmail.com> wrote: > I have seen that most of the targets do comparison and branching > in two separate

I am trying to build cross compiler for custom processor (say XYZ) but on compilation it is giving error llvm-build: error: invalid native target: XYZ (not in project) I have tried configuring like these 1. ./configure --target=XYZ 2. ./configure --target=XYZ --enable-targets=XYZ 3. ./configure --enable-targets=XYZ But every time it is not recognising the XYZ processor. What could be the

You need to add your target to autoconf/configure.ac. Here are the directions from http://llvm.org/docs/WritingAnLLVMBackend.html To get LLVM to actually build and link your target, you need to add it to the TARGETS_TO_BUILD variable. To do this, you modify the configure script to know about your target when parsing the --enable-targets option. Search the configure script for TARGETS_TO_BUILD,

Hi The construct in sparc def LEA_ADDri : F3_2<2, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), "add ${addr:arith}, $dst", [(set IntRegs:$dst, ADDRri:$addr)]>; generate instruction like : add %fp, -20, %l1 in my port it generate like : addi %fp, -20, %r2 But the problem is that our ISA does not support the

Hi Bruno, > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. > What if I want a

On Mon, 7 Jul 2008, Bruno Cardoso Lopes wrote: > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

I want to generate the instruction like addi 40, r3 ! i.e. r3 = r3 + 40 The format i wrote is def ADDI : F1<opcode, (outs IntRegs:$dst), (ins IntRegs:$dst, i32imm:$imm) "addi $imm, $dst", [(set $IntRegs:$dst, (add $IntRegs:$dst, i32imm:$c))] but it is not compiling. what should be the format. vikram -- View this message

Hi sam, On 12/06/2012 17:30, sam wrote: > Hi Ivan, > > The assertion was happening because I wasn't checking after the first > attempt failed. The first packet was failing and so it was ended, and > then the packetizer attempted to add it to the next packet without > checking for available resources. However this highlights probably the > real problem - my packetizer

Hi Ivan, The assertion was happening because I wasn't checking after the first attempt failed. The first packet was failing and so it was ended, and then the packetizer attempted to add it to the next packet without checking for available resources. However this highlights probably the real problem - my packetizer is unable to find resources for the first instruction, or any of my

Thanks for your help, Wei-Ren and Anton. However since I am doing some experiments with klee( http://klee.llvm.org/GetStarted.html) and llvm-gcc seems to have better compatibility with it. So I still hope that I can use llvm-gcc:-) Hongxu Chen On Sat, Mar 16, 2013 at 3:35 PM, 陳韋任 (Wei-Ren Chen) [via LLVM] < ml-node+s1065342n56013h94 at n5.nabble.com> wrote: > Hi Chen, > >

On 07/13/2012 04:30 PM, Duncan Sands wrote: > Hi, > >> I found the -postdomfrontier pass in *llvm*.org/docs/Passes.html, but >> 'opt' does not accept it. I could not find the relevant codes in >> PostDominance.cpp in SVN trunk, but I found some relevant codes here >> http://opensource.apple.com/source/clang/clang-137/src/lib/Analysis/PostDominators.cpp.

Hi shadowkernel, > I searched the archives and found > http://llvm.1065342.n5.nabble.com/post-dominance-frontier-fix-td10221.html > http://llvm.1065342.n5.nabble.com/Is-there-a-control-dependence-graph-builder-td35919.html#a35921 > http://llvm.1065342.n5.nabble.com/post-dominance-frontier-td6783.html > > It seems none of them are relevant. Could you give me more hints about

Thank your reply. Pankaj. Actually, I have done it very similar to yours. But I think for my demand, it is better to implement in Front End. Maybe I will re-implement it later in clang. ---------- Forwarded message ---------- From: Pankaj Gode [via LLVM] <ml-node+s1065342n59345h22 at n5.nabble.com> Date: Mon, Jul 15, 2013 at 2:35 PM Subject: Re: Regarding scope information for variable

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > Hello, > > my target has libcall support for long long shifts. I already have the > following lines in my Lowering constructor: > >   setLibcallName(RTLIB::SHL_I64, "__llshl"); >   setLibcallName(RTLIB::SRL_I64, "__llshru"); >  

Are there best practices regarding how to express saturation arithmetic in LLVM IR? In particular I want to make sure the IR translates efficiently to (SSE) vector instructions when executed in a simple loop. My first thought was to implement this naively by zero extending and branching on the minimum and maximum values. However, I'm also aware of branchfree alternatives[1]. Do the current

Please find the .ll attached below . Yes, I am using the cuda_runtime.h from the toolkit. nbody.kernel.ll <http://llvm.1065342.n5.nabble.com/file/n56048/nbody.kernel.ll> - Uday -- View this message in context: http://llvm.1065342.n5.nabble.com/UNREACHABLE-executed-error-while-trying-to-generate-PTX-tp56026p56048.html Sent from the LLVM - Dev mailing list archive at Nabble.com.