search for: fpexceptions

Hi, this is an RFC for optional, named parameter tuples for intrinsics. The proposed syntax is: %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) where from the perspective of the call site %x, %y and %z are simply additional parameters. Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: ; Default fpenv fadd

Hello everyone, I've just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a could of new token types to be used with constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question. I would like some general feedback on the way I am proposing to use token arguments

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

Hi: I am trying to implement interval arithmetic through llvm. I have a problem with the rounding mode with llvm.experimental.constrained.cos I have two pieces of codes: ; Function Attrs: norecurse nounwind readnone ssp uwtable define double @cosine_down(double returned) local_unnamed_addr #0 {   ; call the llvm intrinsic to perform downward cosine

Intel would like to contribute a patch to implement support for these Intel- and Microsoft -fp options. This message is to describe the options and request feedback from the community. -fp-model=[precise|strict|fast|except[-]] and -fp-speculation=[fast|strict|safe] This contribution would dovetail with the llvm patch "Teach the IRBuilder about constrained fadd and friends" which is

We really have been trying to keep in mind that LLVM needs to support multiple front ends, which may be implementing different language standards. As much as possible, I’ve been trying to let the IEEE 754 spec drive my thinking about this, though I’ll admit that on a few points I’ve use the C99 spec as a sort of reference interpretation of IEEE 754. LLVM’s IRBuilder has been recently updated to

...ining an integer divide. void setIntDivIsCheap(bool isCheap = true) { IntDivIsCheap = isCheap; } + + /// Tells the code generator that this target supports floating point + /// exceptions and cares about preserving floating point exception behavior. + void setHasFloatingPointExceptions(bool FPExceptions = true) { + FloatingPointExceptions = FPExceptions; + } /// Tells the code generator which bitwidths to bypass. void addBypassSlowDiv(unsigned int SlowBitWidth, unsigned int FastBitWidth) { Index: lib/CodeGen/SelectionDAG/SelectionDAG.cpp ================================================...

Hi Craig: I tried that, now the function is like this: ; Function Attrs: norecurse nounwind readnone ssp uwtable define { double, double } @add(double, double, double, double) local_unnamed_addr #0 {   %5 = call double @llvm.experimental.constrained.fadd(double %0, double %2, metadata !"round.downward", metadata !"fpexcept.ignore")   %6 = fadd double %1, %3

Hi: Sorry I need to send email directly. I am new to llvm and trying to write interval arithmetic, which requires changing rounding mode during computation. The document I found https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics, seems to be doing the trick. Here is the piece of code that I did:

Hi Craig: It’s llvm 10.1 I think, I did the same thing, removing everything except the code block but still failed with llvm-as. Thank you Xuan Tang On Sep 3, 2020, 20:14 -0500, Craig Topper <craig.topper at gmail.com>, wrote: > I just pasted that code and ran it through llc, opt, and llvm-as. All passed without issue. What version of llvm are you using? > > ~Craig > > >

...etIntDivIsCheap(bool isCheap = true) { IntDivIsCheap = isCheap; } >> + >> + /// Tells the code generator that this target supports floating point >> + /// exceptions and cares about preserving floating point exception behavior. >> + void setHasFloatingPointExceptions(bool FPExceptions = true) { >> + FloatingPointExceptions = FPExceptions; >> + } >> >> /// Tells the code generator which bitwidths to bypass. >> void addBypassSlowDiv(unsigned int SlowBitWidth, unsigned int FastBitWidth) { >> Index: lib/CodeGen/SelectionDAG/SelectionDAG.c...

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

> > One concern with replacing llvm.rint and llvm.nearbyint with > llvm.roundeven makes it difficult to turn back into a libcall if the > backend doesn't have an instruction for it. You can't just call the > roundeven library function since that wouldn't exist in older libm > implementations. So ideally you would know which function was originally > used in the

> > 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`,

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

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

Copying the list on a discussion of potentially general interest.... From: Kaylor, Andrew Sent: Friday, November 03, 2017 1:11 PM To: 'Ding, Wei' <Wei.Ding2 at amd.com>; Sumner, Brian <Brian.Sumner at amd.com>; Arsenault, Matthew <Matthew.Arsenault at amd.com> Subject: RE: clarification needed for the constrained fp implementation. Hi Wei, I've been meaning to

Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires

Hi, I’ve been investigating https://bugs.llvm.org/show_bug.cgi?id=43374, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting ARM, in the below code example. int bar(float x) { return x!=x ? 0 : 1; } The C99 standard states in section 7.12.14: """ The relational and equality operators support the usual mathematical