similar to: [LLVMdev] llvm-3.1 with "native" half support alpha version

Hi Nikos, You can model your requirement in the *.td using RegisterClass as def SrcRegs : RegisterClass<"Src", [i32], 4, (add R0, R2, R4, R6 )>; def DstRegs : RegisterClass<"Dst", [i32], 4, (add R1, R3, R5, R7 )>; Thanks ~Umesh On Thu, Nov 7, 2013 at 8:25 PM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > Hi all.

hi all, i am trying to implement native support for fp16 in llvm-3.1 i have already used the opencl patch for clang so the IR that is generated is correct. i tried to add some code so the the fp16 type is handled correctly but no luck. We have a target that has native fp16 units and tried to run a simple program int main () { __fp16 a,b,c,d; a= 1.1; b=2.2; c=3.3;

Could you file a bug? On Wed, Feb 27, 2013 at 2:47 AM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > i have this code > > typedef long long L; > typedef integer I; > void test2(auto L p0, auto L p1, auto L p2, auto L p4, ...) > { > va_list select; > > va_start (select, p4); > > report( va_arg(select,L) ); > report(

Hi all. if there is limitation for the registers to be used together in an instruction, should i try to change it in the register allocation pass or should i try it somewhere else?? example. lets say we have to add 2 registers addu rx ,ry ,rz there is a limitation that says that the two regs that will be added they can not have the same mod4 so we can add r1 , r2 but cannot add r1,r5.

hi all I have a question about implementing a new instruction which does this function f(x) = x + ceilf (x) .x is a single float i have already added the instruction in my backend in the .td file def SUBCEIL_S : FFR<0x11, 0x3, 16, (outs FGR32:$fd), (ins FGR32:$fs), "frac.s\t$fd, $fs", [(set (f32 FGR32:$fd), (fadd (f32 FGR32:$fs ),(f32 (ceilf FGR32:$fs))))] >; it makes

i have this code typedef long long L; typedef integer I; void test2(auto L p0, auto L p1, auto L p2, auto L p4, ...) { va_list select; va_start (select, p4); report( va_arg(select,L) ); report( va_arg(select,I) ); report( va_arg(select,L) );

Hi Nikos > and when i try to call llc produces this error > > LLVM ERROR: Cannot select: 0x234bab0: f16 = fadd 0x234b8b0, 0x234c2b0 > [ORD=9] [ID=29] This error suggests things are working on the generic LLVM side (as I'd expect). It's what I'd expect to see for your code snippet if there wasn't a target-specific pattern that could handle the addition properly and

after a long time i managed to make a progress with this problem. i can store and load fp16 as i16 in to some registers and do an add instruction. the problem now is that this messes up the real i16 (short, unsigned short). i have def FADD_H : NemaCorePseudo< (outs HGR16:$fd), (ins HGR16:$fs, HGR16:$ft), "add.h\t$fd, $fs, $ft", [(set (i16 HGR16:$fd),(i16 (f32_to_f16 (f32 (fadd (f32

i understand that is not right but this was the only way not to use the fadd for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything to the float registers and did add.s and not the half add.h is there any trick to do that? i tried a lot but with no luck -- View this message in context:

> def FADD_H : NemaCorePseudo< (outs HGR16:$fd), (ins HGR16:$fs, HGR16:$ft), > "add.h\t$fd, $fs, $ft", [(set (i16 HGR16:$fd),(i16 (f32_to_f16 (f32 (fadd > (f32 (f16_to_f32 (i16 HGR16:$fs))), > (f32 (f16_to_f32 (i16 HGR16:$ft))))))))]>; > > so i can have a half floating point add two half point variables and seems > to work fine. This does not look right. Note

> i understand that is not right but this was the only way not to use the fadd > for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything > to the float registers and did add.s and not the half add.h It seems you do not understand the issue. Half floating poing operations can be done in two ways: 1. Storage-only (fp16 is used to store value, all

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

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.

hello, I read that you do implement these operations in your backend some time ago. (http://llvm.1065342.n5.nabble.com/llvm-dev-Questions-about-load-store-incrementing-address-modes-td87577.html). The DAGCombiner::CombineToPostIndexedLoadStore(SDNode *N) function never works for me. Can you show me a code fragment in C which is translated into pre/post dec/inc load/store? Then I will be able to