search for: strictfp

...instruction basis. If the backend wants to handle that by using the strictest >rule that it sees in use anywhere in the function because pattern-matching is otherwise too >error-prone, ok, that's its right; but the IR really should be per-instruction. I added a function level attribute, strictfp, which is meant to help with this. I don’t believe the inlining handling of the attribute is implemented yet, but what I’m thinking is that we would never inline a function that had the strictfp attribute and if we inlined a non-strictfp function into a strictfp function, we would transform any FP...

> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we’re

...instruction basis. If the backend wants to handle that by using the strictest >rule that it sees in use anywhere in the function because pattern-matching is otherwise too >error-prone, ok, that's its right; but the IR really should be per-instruction. I added a function level attribute, strictfp, which is meant to help with this. I don’t believe the inlining handling of the attribute is implemented yet, but what I’m thinking is that we would never inline a function that had the strictfp attribute and if we inlined a non-strictfp function into a strictfp function, we would transform any FP...

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

...between llvm.rint and llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint completely. As for the target-specific intrinsics, you are correct that we need a plan for that. I have given it some thought, but nothing is currently implemented. My suggestion would be that we should set the strictfp attribute on these intrinsics and provide the rounding mode and exception behavior arguments using an operand bundle. We do still need some way to handle the side effects. My suggestion here is to add some new attribute that means “no side effects” in the absence of the strictfp attribute and somet...

...ding is based on a call to tanh made by the compiler. The problem with this is that if I am linking my program against a different version of the math library than was used by the compiler I may get a different result. I can prevent this constant folding with either the 'nobuiltin' or 'strictfp' attribute. However, it seems to me like this optimization should really be checking the 'afn' fast math flag. Opinions? Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/aa3a...

...he way, X86 target also has such property: EVEX prefix allows static rounding support or suppress-all-exceptions. Such properties are naturally modeled with metadata operands but splitting to constrained and non-constrained variants makes little sense. My suggestion would be that we should set the strictfp attribute on these > intrinsics and provide the rounding mode and exception behavior arguments > using an operand bundle. This is an interesting variant. IIUC it means that FP environment is a property of a call rather that an instruction? That is some call may have rounding mode argument a...

...VEX prefix >> allows static rounding support or suppress-all-exceptions. Such properties >> are naturally modeled with metadata operands but splitting to constrained >> and non-constrained variants makes little sense. >> >> My suggestion would be that we should set the strictfp attribute on these >>> intrinsics and provide the rounding mode and exception behavior arguments >>> using an operand bundle. >> >> >> This is an interesting variant. IIUC it means that FP environment is a >> property of a call rather that an instruction? T...

...ng is based on a call to tanh made by the compiler. The problem with this is that if I am linking my program against a different version of the math library than was used by the compiler I may get a different result. I can prevent this constant folding with either the 'nobuiltin' or 'strictfp' attribute. However, it seems to me like this optimization should really be checking the 'afn' fast math flag. Opinions? Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2019041...

On 10/03, Kaylor, Andrew via llvm-dev wrote: > I’d like to emphasize that the constrained intrinsics prevent > optimizations *by default*. We have a plan to go back and teach > individual optimizations how to handle these intrinsics. The idea is > that if an optimization knows nothing about the constrained intrinsics > then it won’t try to transform them, but if an optimization has

...constant folding is based on a call to tanh made by the compiler. The problem with this is that if I am linking my program against a different version of the math library than was used by the compiler I may get a different result. I can prevent this constant folding with either the ‘nobuiltin’ or ‘strictfp’ attribute. However, it seems to me like this optimization should really be checking the ‘afn’ fast math flag. Opinions? Thanks, Andy _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llv...

Let me clarify. These aren’t intended to be exposed to the user. The user code that leads to the generation of these intrinsics will be normal floating point operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or command line options (such as the recently introduced “-fp-model=strict”). The reason I’ve been avoiding normal constant values is that it provides no information when