search for: fpext

For the following C code __fp16 x, y, z, w; void foo() { x = y + z; x = x + w; } clang produces IR that extends each operand to float and then truncates to half before assigning to x. Like this define dso_local void @foo() #0 !dbg !18 { %1 = load half, half* @y, align 2, !dbg !21 %2 = fpext half %1 to float, !dbg !21 %3 = load half, half* @z, align 2, !dbg !22 %4 = fpext half %3 to float, !dbg !22 %5 = fadd float %2, %4, !dbg !23 %6 = fptrunc float %5 to half, !dbg !21 store half %6, half* @x, align 2, !dbg !24 %7 = load half, half* @x, align 2, !dbg !25 %8 = fpext half %7 to float, !...

...tom at stellard.net> wrote: > On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote: >> Hi all, >> >> What do people think of doing away with the @llvm.convert.to.fp16 and >> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and >> fpext/fptrunc? [1] >> > > I am in favor of using fpext/fptrunc instead of the intrinsics. The problem with this is the half type assumes you have half registers. I came up with some ugly hack that involved forcing custom lowering to make half loads/stores work for R600, but it was much ea...

...; > x = x + w; > > } > > > > clang produces IR that extends each operand to float and then truncates to > half before assigning to x. Like this > > > > define dso_local void @foo() #0 !dbg !18 { > > %1 = load half, half* @y, align 2, !dbg !21 > > %2 = fpext half %1 to float, !dbg !21 > > %3 = load half, half* @z, align 2, !dbg !22 > > %4 = fpext half %3 to float, !dbg !22 > > %5 = fadd float %2, %4, !dbg !23 > > %6 = fptrunc float %5 to half, !dbg !21 > > store half %6, half* @x, align 2, !dbg !24 > > %7 = load half...

...i32 0 } BUT if I change the value of the variable 'a' to be '7.1'. then a correct IR is generated: ... entry: store i32 0, i32* @err, align 4, !tbaa !0 ret i32 0 ... I have already investigated the issue and found that during the EarlyCSE transformation it seems replaces the FPExt instruction with an incorrect hexadecimal value: The LLVM IR generated with O0 opt. level is: ... store float 0x4020333340000000, float* %a, align 4 %0 = load float* %a, align 4 %conv = fpext float %0 to double %sub = fsub double %conv, 8.100000e+00 %cmp = fcmp oge double %sub, 0x3E800000...

...fine when using optimizations, but when I disable optimizations, It turns into a sequence of instructions that I can't figure out what to setup to get it to generate the correct code. The instructions in question are: %tmp1 = load float* %test ; <float> [#uses=1] %conv = fpext float %tmp1 to double ; <double> [#uses=1] Which emits the following dag: f64,ch = load 01809908, 018092A8, 01809110 <0035A544:0> <anyext f32> alignment=4 If the load and the fpext were emitted seperatly, I could handle them with my fpext and load patterns in...

...le 'a' to be '7.1'. then a correct IR > is generated: > ... > entry: > store i32 0, i32* @err, align 4, !tbaa !0 > ret i32 0 > ... > > > I have already investigated the issue and found that during the EarlyCSE > transformation it seems replaces the FPExt instruction with an incorrect > hexadecimal value: > The LLVM IR generated with O0 opt. level is: > ... > store float 0x4020333340000000, float* %a, align 4 > %0 = load float* %a, align 4 > %conv = fpext float %0 to double > %sub = fsub double %conv, 8.100000e+00 > %cmp...

Hi all, What do people think of doing away with the @llvm.convert.to.fp16 and @llvm.convert.from.fp16 intrinsics, in favour of using "half" and fpext/fptrunc? [1] It looks like those intrinsics originally date from before "half" actually existed in LLVM, and of course the backends have grown up assuming that's what Clang will produce, so we'd have to improve their support first. But the benefit would be a more uniform interfac...

Hello I want to transfer value (Value* src) of the type `FloatTyID` to `DoubleTyID`(I need all floats to be saved as 8 bytes).I have tried: builder.CreateCast(llvm::Instruction::FPExt, src, llvm::Type::getDoubleTy(llvmContext),””) I don`t know if I use CreateCast correctly and if this approach is correct at all. Thank you. Yakov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111114/8f...

...ntry: %result.addr = alloca float*, align 8 %x.addr = alloca float, align 4 %y.addr = alloca float, align 4 store float* %result, float** %result.addr, align 8 store float %x, float* %x.addr, align 4 store float %y, float* %y.addr, align 4 %tmp = load float* %x.addr, align 4 %conv = fpext float %tmp to double %tmp1 = load float* %y.addr, align 4 %conv2 = fpext float %tmp1 to double %div = fdiv double %conv, %conv2 %conv3 = fptrunc double %div to float %tmp4 = load float** %result.addr, align 8 store float %conv3, float* %tmp4 ret void } ----- With optimisations turned...

...; preds = %for.cond %5 = load float* %arrayidx, align 4 store float %5, float* %x, align 4 %6 = load float* %arrayidx1, align 4 store float %6, float* %y, align 4 %7 = load float* %arrayidx2, align 4 store float %7, float* %z, align 4 %8 = load float* %x, align 4 %conv = fpext float %8 to double %mul = fmul double %conv, 6.700000e-01 %9 = load float* %y, align 4 %conv3 = fpext float %9 to double %mul4 = fmul double %conv3, 1.700000e-01 %add = fadd double %mul, %mul4 %10 = load float* %z, align 4 %conv5 = fpext float %10 to double %mul6 = fmul double %conv...

It doesnt work it fails with assertation that cast is invalid .What could be done? On 11/14/11, Duncan Sands <baldrick at free.fr> wrote: > Hi Yakov, that looks correct to me. You can also use CreateFPExt which is > slightly simpler. > > Ciao, Duncan. > > >> I want to transfer value (Value* src) of the type `FloatTyID` to >> `DoubleTyID`(I >> need all floats to be saved as 8 bytes).I have tried: >> >> builder.CreateCast(llvm::Instruction::FPExt, src,...

...ral > case as necessary. I have a rough draft of a patch for this that works reasonably well for simple cases... I don't think I really have the time to finish it properly, but I'll clean it up a bit and send it to you as a starting point. > 2) Vector strunc, sext, zext, fptrunc and fpext > > Again, I think these are hopefully straightforward. Please let me know > if you expect any issues with vector operations that change element > sizes from the RHS to the LHS, e.g. around legalization. These are tricky to generate efficient code for because they change the size of th...

...or.cond > %5 = load float* %arrayidx, align 4 > store float %5, float* %x, align 4 > %6 = load float* %arrayidx1, align 4 > store float %6, float* %y, align 4 > %7 = load float* %arrayidx2, align 4 > store float %7, float* %z, align 4 > %8 = load float* %x, align 4 > %conv = fpext float %8 to double > %mul = fmul double %conv, 6.700000e-01 > %9 = load float* %y, align 4 > %conv3 = fpext float %9 to double > %mul4 = fmul double %conv3, 1.700000e-01 > %add = fadd double %mul, %mul4 > %10 = load float* %z, align 4 > %conv5 = fpext float %10 to double > %...

...is invalid .What >> could be done? >> > > Maybe src doesn't have Float type? > > Ciao, Duncan. > > > >> >> On 11/14/11, Duncan Sands<baldrick at free.fr> wrote: >> >>> Hi Yakov, that looks correct to me. You can also use CreateFPExt which >>> is >>> slightly simpler. >>> >>> Ciao, Duncan. >>> >>> >>> I want to transfer value (Value* src) of the type `FloatTyID` to >>>> `DoubleTyID`(I >>>> need all floats to be saved as 8 bytes).I have tried...

...ry to remeber to send > semething to -dev when major stuff appears. Good. I am also trying to sending a patch to llvm-commits. It'd be better for me to use [AVX] prefix in the subject so that we can easily identify "This is an AVX patch" to avoid duplicated work? I've sent a fpext codegen patch. Next I am working is sitofp codegen path. -- Syoyo

Hi Yakov, that looks correct to me. You can also use CreateFPExt which is slightly simpler. Ciao, Duncan. > I want to transfer value (Value* src) of the type `FloatTyID` to `DoubleTyID`(I > need all floats to be saved as 8 bytes).I have tried: > > builder.CreateCast(llvm::Instruction::FPExt, src, > llvm::Type::getDoubleTy(llvmContext),””)...

...rote: > It doesnt work it fails with assertation that cast is invalid .What > could be done? Maybe src doesn't have Float type? Ciao, Duncan. > > > On 11/14/11, Duncan Sands<baldrick at free.fr> wrote: >> Hi Yakov, that looks correct to me. You can also use CreateFPExt which is >> slightly simpler. >> >> Ciao, Duncan. >> >> >>> I want to transfer value (Value* src) of the type `FloatTyID` to >>> `DoubleTyID`(I >>> need all floats to be saved as 8 bytes).I have tried: >>> >>> builder....

I've isolated a bug in SSE codegen to the attached example. define void @f(<2 x float>* %in, <2 x double>* %out) { entry: %0 = load <2 x float>* %in, align 8 %1 = fpext <2 x float> %0 to <2 x double> store <2 x double> %1, <2 x double>* %out, align 1 ret void } The code should load a <2 x float> vector from %in, fpext cast it to a <2 x double>, and do an unaligned store (movupd) of the result to %out. This works as expec...

Ralf Karrenberg <Chareos at gmx.de> writes: > This sounds great! > > For my case, I only require some basic support, so I am optimistic > that your next few patches will provide everything I need. If my evil plan works out, within the next 10 or so patches we should be in a place where pushing everything up goes pretty quickly. It's about 8 TableGen patches and then a

...r a LLVM code target, I am developing a software-supported floating-point engine. I've come into a few issues in which the DAG conversion is Can anyone help with: I have some C code test like: float x; printf("%f", x); which clang coverts to: %0 = load float* @x, align 4 %conv = fpext float %0 to double The issue is for simple Float to Double extension, the DAGCombiner.cpp DAGCombiner::visitFP_EXTEND(SDNode *N) is making a decision to do a load extension, and it translates into doing a simple double load. But problem is that my target can't simple load 8 bytes from the 4 b...