search for: fastmathflag

...Let's see if we can agree on a more future proof solution. -- Sanjoy > > ~Craig > > > On Sat, Mar 16, 2019 at 12:51 PM Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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....

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...

...he flags at the bottom of value by > shrinking NumUserOperands to 27? > > ~Craig > > > On Sat, Mar 16, 2019 at 12:51 PM Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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....

On Nov 14, 2012, at 5:13 PM, Michael Ilseman <milseman at apple.com> wrote: > I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all the other content. > > <bitcode_example.patch> > > Does this patch make sense, or am I still missing the main concern? > Michael, Ah I...

...at arxan.com> wrote: > > > On Nov 14, 2012, at 5:13 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all the other content. >> >> <bitcode_example.patch> >> >> Does this patch make sense, or am I still missing the main concern? >&g...

I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all the other content. -------------- next part -------------- A non-text attachment was scrubbed... Name: bitcode_example.patch Type: application/octet-stream Size...

...this change (of removing the "fast" umbrella flag, and adding the two new flags "reassoc" and "libm"), is to audit all the places that currently enable an optimization based on whether ‘hasUnsafeAlgebra()’ is true (which essentially is asking whether _all_ the existing FastMathFlags are enabled), and see which of them can/should be controlled by one (or a subset of) the full set. So it's possible that a particular slow sequence of inline instructions you are transforming would be controlled by "libm", and a different slow sequence of inline instructions would b...

On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal

Hi, Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the

...r-developer-guide-and-reference-fp-model-fp Currently, clang's default behavior corresponds to -fp-model=precise. Clang/llvm support for -fp-model=[strict|except] is being developed in the D53157 patch, and there is current llvm support for the fast settings by using the fast math flags llvm::FastMathFlags. Note: the clang-cl wrapper to support Microsoft options has simplified support for these options by mapping /fp-model=except to ftrapping-math, fp-mdel=fast to ffast-math, fp-model=precise and fp-model=strict to fno-fast-math (see clang/Driver/CLCompatOptions.td). According to the online option...

...this change (of removing the "fast" umbrella flag, and adding the two new flags "reassoc" and "libm"), is to audit all the places that currently enable an optimization based on whether ‘hasUnsafeAlgebra()’ is true (which essentially is asking whether _all_ the existing FastMathFlags are enabled), and see which of them can/should be controlled by one (or a subset of) the full set. So it's possible that a particular slow sequence of inline instructions you are transforming would be controlled by "libm", and a different slow sequence of inline instructions would b...

...for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of the FastMathFlags class. (2) and (3) should probably depend on it. If the flag is set, (2) and (3) cannot be folded as there are no NaNs and we are not guaranteed to get an arbitrary bit pattern from fadd, right? Other arithmetic FP operations (fsub, fmul, fdiv) also propagate NaNs. Thus, the same rules seem app...

...recognize intrinsics > gets us a long way. But we'd also need to update IR passes in places > where the Opcode is explicitly checked. E.g.: > > ``` > switch (Opcode) { > <snipped> > case Instruction::FAdd: <== ***HERE*** > return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); > ``` > > And when a transformation succeeds, we'd need to update how the result > is returned. E.g.: > > ``` > // (-X) + Y --> Y - X > Value *X, *Y; > if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) > return BinaryOperator...

...at teaching the pattern matcher to recognize intrinsics gets us a long way. But we'd also need to update IR passes in places where the Opcode is explicitly checked. E.g.: ``` switch (Opcode) { <snipped> case Instruction::FAdd: <== ***HERE*** return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); ``` And when a transformation succeeds, we'd need to update how the result is returned. E.g.: ``` // (-X) + Y --> Y - X Value *X, *Y; if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) return BinaryOperator::CreateFSubFMF(Y, X, &I); <== ***HER...

...IR level. I wouldn’t be opposed to have something along the line of “aggr”, but there is a tradeoff: some transformation may be harder to guard with this model. Maybe that could be a starting point: changing the “UnsafeAlgebra” bit in the FMF to be “aggr” you mention and replace all the query to FastMathFlags::UnsafeAlgebra() to return true if all the bits are set in the Flags. This alone should be nothing more than a mechanical change I believe. The important part is then auditing all the users of UnsafeAlgebra() in the middle end and check if they can be “downgraded” to aggr safely: i.e. if they don’...

..., Michael Ilseman <milseman at apple.com> wrote: >> Ah I see. So this just becomes a matter of interpretation of bits in the optimization flags. Shouldn't need to promote the CurVersion. >> >> Nitpick: 80-cols in BitcodeReader.cpp >> >> Since Instruction::FastMathFlags is a class, seems like the constructor could take in Record[OpNum] , and assign the flags. >> > > I like the intent, but unfortunately Record[OpNum] is just a uint64_t. The agreement of which bit means what is in LLVMBitCodes.h, and I'd prefer not having an implicit handshake bet...

...>> (2) fadd undef, undef -> undef >> (3) fadd %x, undef -> NaN (undef is a NaN which >> is propagated) >> >> Looking through the code I found the "NoNaNs" flag accessed through >> an instance >> of the FastMathFlags class. >> (2) and (3) should probably depend on it. >> If the flag is set, (2) and (3) cannot be folded as there are no NaNs >> and we are >> not guaranteed to get an arbitrary bit pattern from fadd, right? > > I think it's exactly the other way round: if NoNans...

...ecognize intrinsics > gets us a long way. But we'd also need to update IR passes in places > where the Opcode is explicitly checked. E.g.: > > ``` > switch (Opcode) { > <snipped> > case Instruction::FAdd: <== ***HERE*** > return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); > ``` > > And when a transformation succeeds, we'd need to update how the result > is returned. E.g.: > > ``` > // (-X) + Y --> Y - X > Value *X, *Y; > if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) > return BinaryOperat...

...I wouldn’t be opposed to have something along the line of “aggr”, but there is a tradeoff: some transformation may be harder to guard with this model. > > Maybe that could be a starting point: changing the “UnsafeAlgebra” bit in the FMF to be “aggr” you mention and replace all the query to FastMathFlags::UnsafeAlgebra() to return true if all the bits are set in the Flags. This alone should be nothing more than a mechanical change I believe. > The important part is then auditing all the users of UnsafeAlgebra() in the middle end and check if they can be “downgraded” to aggr safely: i.e. if they...

...when we will decide to fully support `declare variant`. The information it carries will not need to be invalidated, but just extended with new attributes that will need to be handled by the `VectorFunctionShape` class, in a similar way the `llvm::FPMathOperator` does with the `llvm::FastMathFlags`, which operates on individual attributes to describe an overall functionality. # Examples ## Example 1 Exposing an Advanced SIMD vector function when targeting Advanced SIMD in AArch64. ``` double foo_01(double Input) __attribute__(clang_declare_simd_variant(“vector_foo_01", simdl...