search for: fpenv

...gs to the existing FMF (fast-math flags). Without these flags set, the optimizer has to assume that the FP env can be observed, or the rounding mode can be changed. For clang, these flags would be set unless a command line option would require to preserve the FP env. Here is the list of patches: [FPEnv Core 01/14] Add flags and command-line switches for FPEnv: http://reviews.llvm.org/D14066 [FPEnv Core 02/14] Add FPEnv access flags to fast-math flags: http://reviews.llvm.org/D14067 [FPEnv Core 03/14] Make SelectionDAG aware of FPEnv flags: http://reviews.llvm.org/D14068 [FPEnv Core 04/14] Skip co...

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map rint() user call...

...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 (isomorphic to the fadd instruction) %z = call double @llvm.fadd(%a, %b) ; Constrained fp add %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) %x = call <256 x...

...lags). Without these flags set, the optimizer has to assume that > the FP env can be observed, or the rounding mode can be changed. For > clang, these flags would be set unless a command line option would > require to preserve the FP env. > > Here is the list of patches: > > [FPEnv Core 01/14] Add flags and command-line switches for FPEnv: > http://reviews.llvm.org/D14066 > [FPEnv Core 02/14] Add FPEnv access flags to fast-math flags: > http://reviews.llvm.org/D14067 > [FPEnv Core 03/14] Make SelectionDAG aware of FPEnv flags: > http://reviews.llvm.org/D14068 &...

...has to assume that > > the FP env can be observed, or the rounding mode can be changed. > > For > > clang, these flags would be set unless a command line option would > > require to preserve the FP env. > > > > Here is the list of patches: > > > > [FPEnv Core 01/14] Add flags and command-line switches for FPEnv: > > http://reviews.llvm.org/D14066 > > [FPEnv Core 02/14] Add FPEnv access flags to fast-math flags: > > http://reviews.llvm.org/D14067 > > [FPEnv Core 03/14] Make SelectionDAG aware of FPEnv flags: > > http://...

...bserved, or the rounding mode can be changed. >>>> For >>>> clang, these flags would be set unless a command line option would >>>> require to preserve the FP env. >>>> >>>> Here is the list of patches: >>>> >>>> [FPEnv Core 01/14] Add flags and command-line switches for FPEnv: >>>> http://reviews.llvm.org/D14066 >>>> [FPEnv Core 02/14] Add FPEnv access flags to fast-math flags: >>>> http://reviews.llvm.org/D14067 >>>> [FPEnv Core 03/14] Make SelectionDAG aware of FP...

Hey llvm-dev, Continuing a discussion from D50913... A group working on the FP rounding mode and trap-safety project have run into a situation where it would make sense to add a new FNEG instruction and decouple the existing FNEG<->FSUB transformations. The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and sub(-0.0,x) are two different operations. The former is a bitwise

...new fneg instruction. Is this a promise we want to make? From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 2:30 PM To: Kevin Neal <Kevin.Neal at sas.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction EXTERNAL On Wed, Sep 26, 2018 at 2:14 PM Kevin Neal via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Do we really want to have fneg be the only instruction with guaranteed no side effects? That just sounds like a gotcha waiting to h...

...Host Research and Development SAS Institute, Inc. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Sanjay Patel via llvm-dev Sent: Wednesday, September 26, 2018 1:25 PM To: cameron.mcinally at nyu.edu Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction To bring it back to the question of fneg, let me know if this is an accurate summary: 3. We want fneg as a 1st class instruction even though the related fabs/copysign bitstring ops are intrinsics (because fneg is more common than the others?). 4. Adding fneg to IR means we do no...

...3406, for example: _mm256_cmp_ps("any input", "any input", _CMP_TRUE_UQ) should produce -1, -1, -1, ... vector, but for some values for example "1.00 -nan" if FPU exceptions were enabled this operation triggers the exception. Here is the question: Should we assume that FPENV was initialized with FE_ALL_EXCEPT by default or we could rely for example on "-fno-trapping-math" flag or we could completely ignore the FPU exception issue(see https://bugs.llvm.org/show_bug.cgi?id=6050)? Thanks, Dinar.

...ormant to IEEE-754 and not require any actual changes in LLVM (since it's what CPUs would do anyway). I think that's uglier than adding FNEG though. > Is correcting this behavior something that the general LLVM population would like? If not, we can create constrained intrinsics for the FPEnv project. I'm in favour of FNEG too. I remember the fsub trick being confusing when I first encountered it. Cheers. Tim.

On Tue, Oct 2, 2018 at 12:09 PM Kevin Neal <Kevin.Neal at sas.com> wrote: > If we don’t have constrained intrinsics for some of the fp math > instructions then aren’t we risking non-strict optimizations? > So far we've only added constrained FP intrinsics for operations that have side effects (i.e. can trap). The quiet-computational sign-bit operations are special. They never

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FSUB(-0.0, NaN) = NaN > FSUB(-0.0, -NaN) = NaN Some specific architecture may define this, or APFloat might, but IEEE 754 does not interpret the sign of NaN except in four operations (copy, abs, negate, copysign), so it doesn’t say anything about these. – Steve --------------

On Thu, Aug 30, 2018 at 11:14 AM, Tim Northover <t.p.northover at gmail.com> wrote: > ... > I don't think it matters for the question at hand, but I tested > AArch64 too and it exhibits the behaviour you were describing. That > is, we'd have problems if an fsub -0.0 was actually CodeGened like > that (it's not, of course). Great data point. So it's not just

...forever, then the documentation should say that clearly. From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 3:03 PM To: Kevin Neal <Kevin.Neal at sas.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction EXTERNAL On Wed, Sep 26, 2018 at 2:47 PM Kevin Neal <Kevin.Neal at sas.com<mailto:Kevin.Neal at sas.com>> wrote: Well, yes, they are different operations. And, yes, this needs to be corrected. This wasn’t my point. It’s a given. I was getting at the _declared_ absen...

On Wed, Sep 26, 2018 at 9:32 AM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> >> This is the first time I'm looking at foldShuffledBinop(...), so maybe a >> naive question, but why not do similar shuffle canonicalizations on unary >> (or

Regarding non-IEEE targets: yes, we definitely support those, so we do have to be careful about not breaking them. I know because I have broken them. :) See the discussion and related links here: https://reviews.llvm.org/D19391 But having an exactly specified fneg op makes that easier, not harder, as I see it. Unfortunately, if a target doesn't support this op (always toggle the sign bit and

I've got a ticket open where I would very much like some input from maintainers of other languages that rely on llvm and use the IRBuilder. See: Teach the IRBuilder about constrained fadd and friends: https://reviews.llvm.org/D53157 I'm adding support to functions like CreateFAdd() the ability to optionally emit the constrained math intrinsics required to support strict floating point

On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: > >> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> FSUB(-0.0, NaN) = NaN >> FSUB(-0.0, -NaN) = NaN >>