search for: fpextend

...und (v4f32 VF32:$src)))] and 'CONV_v4f32_v4f16'. What adjustments do I need to make to the TD descriptions to make these work again? I know that FP16 is not hugely common on the mainstream platforms, but it is vital to ours. I did notice that 'fextend' was replaced by 'fpextend', is there some new ISD node type I should use for 'fround'? Thanks, MartinO -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170123/7335c629/attachment.html>

...id @dpdiv(float* nocapture %result, float %x, float %y) nounwind uwtable { entry: %conv3 = fdiv float %x, %y store float %conv3, float* %result, align 4, !tbaa !1 ret void } ----- The main optimisation applied here is near the top of InstCombiner::visitFPTrunc, which simplifies fptrunc(fdiv (fpextend x), (fpextend y)) to fdiv(x, y). Because double precision floating point divides are accurate in OpenCL, the single precision divide in the optimised code must also be accurate, unlike a "direct" single precision divide. I would imagine that creating a pinned metadata name for fpaccuracy...

Peter, Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Robert Quill > Sent: Thursday, September 08, 2011 3:24 AM > To: Peter

Hi Peter, This sounds like I really good idea. One thing that did occur to me though from an OpenCL point of view is that ULP accuracy requirements can differ for embedded and full profile so that may need to be handled somehow. Thanks, Rob On Wed, 2011-09-07 at 21:55 +0100, Peter Collingbourne wrote: > Hi, > > This is my proposal to add floating point accuracy support to LLVM. >

..._fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", []>, Requires<[HasFP16]>, Sched<[WriteFPCVT]>; def : FP16Pat<(f16_to_fp GPR:$a), (VCVTBHS (COPY_TO_REGCLASS GPR:$a, SPR))>; def : FullFP16Pat<(f32 (fpextend HPR:$Sm)), (VCVTBHS (COPY_TO_REGLASS HPR:$Sm, SPR)>; I'm not sure of the COPY_TO_REGLASS semantics, but I would (dangerously) assume that it when it comes to copying the values between registers, it will be noticed that HPR and SPR actually alias each other and so no cop...

I'm trying to fix a bug in the PowerPC SPE backend that prevents a bunch of FreeBSD ports from building, including gtk20. The attached file, generated from the following C source, triggers the "Def == PreviousDef" assertion in isNopCopy(): typedef float a; typedef struct { a b, c; } complex; d(complex *e, complex *h) { double f = h->c, g = h->b; i(g); e->c = g *

...e hard way that the conversion are the tricky ones, so I repeat this for an f16 -> f32 upconvert: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins HPR:$Sm), IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Requires<[HasFP16]>, Sched<[WriteFPCVT]>; This new rule matches and fp_extend that consumes an HPR and produces a result in SPR. And that's essentially it and all the code changes I wa...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

Hi, The last time the AVX backend was mentioned on this list seems to be from November 2010, so I would like to ask about the current status. Is anybody (e.g. at Cray?) still actively working on it? I have tried both LLVM 2.9 final and the latest trunk, and it seems like some trivial stuff is already working and produces nice code for code using <8 x float>. Unfortunately, the backend