search for: md_fpmath

...nt. This function won't to remove a previously set tag, which could be used by optimisations or inlining. + Instruction *AddFPMathTag(Instruction *I, MDNode *FPMathTag) const { + if (!FPMathTag) + FPMathTag = DefaultFPMathTag; + if (FPMathTag) + I->setMetadata(LLVMContext::MD_fpmath, FPMathTag); + return I; + } If you want to keep it as only Add, then make FPMathTag = 0 so that you can easily add the default by just calling AddFPMathTag(instr); But I'd add a ClearFPMathTag function for optimisations/inlining. Maybe later. Also, would be good to make sure the instruc...

Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +

...y 2-5% FP ops. The rest is the same load/store/control-flow/ALU stuff found in integer code. I'm not exactly sure yet what it would take to do the experiment, but it seems worth exploring moving the existing FMF to metadata. One point in favor of this approach is that we already have an "MD_fpmath" enum. It's currently only used to convey reduced precision requirements to the AMDGPU backend. We could extend that to include arbitrary FMF settings. A couple of related points for FMF-as-metadata: 1. It might encourage fixing a hack added for reciprocals: we use a function-level attrib...

...d we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can share the > struct with the backend's SDNodeFlags, but that already has one extra > bit for vector reduction. Should we give up on SubclassOptionalData > for FMF? We have a MD_fpmath enum value for metadata, so we could move > things over there? I agree that using SubclassOptionalData is going to be problematic when we run out of bits. As I recall, the reason that we didn't use metadata in the first place was because metadata is (generically) expensive. This case is...

...ssOptionalData of Value...and we have exactly 7 bits there. :) If we're redoing the definitions, I'm wondering if we can share the struct with the backend's SDNodeFlags, but that already has one extra bit for vector reduction. Should we give up on SubclassOptionalData for FMF? We have a MD_fpmath enum value for metadata, so we could move things over there? On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >&gt...

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

Hi, I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, but we've already used up the 7 bits available in Value::SubclassOptionalData (the "backing storage" for FPMathOperator::getFastMathFlags()). These are the possibilities I can think of: 1. Increase the size of FPMathOperator. This gives us some additional bits for FTZ and other fastmath flags we'd want

...ctly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can share > the struct with the backend's SDNodeFlags, but that already has > one extra bit for vector reduction. Should we give up on > SubclassOptionalData for FMF? We have a MD_fpmath enum value for > metadata, so we could move things over there? > > On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Hal, > > >> 4. To fix this,...

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' +

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Warren Ristow" <warren.ristow at sony.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, November 15, 2016 11:10:48 PM > Subject: Re: [llvm-dev] RFC: Consider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi,