similar to: [RFC] FP Environment and Rounding mode handling in LLVM

Hi Chandler, This scheme has significant advantages over what was being pursued, but one question (or two)... Under the proposed system, how would you represent the necessary dependency edges between the fp intrinsics and function calls? How is the state 'returned' to the caller? [I was thinking that our new operand bundles could help for the inputs, but the outputs? Plus what about the

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, February 5, 2016 4:36:54 PM > Subject: Re: [llvm-dev] [RFC] FP Environment and Rounding mode

FWIW, +1 from me. Just one request on the implementation though. However we model these intrinsics and their properties (metadata, constants, etc), can we please abstract away those details the same way we have MemCpyInst which just wraps an IntrinsicInst? I think this would be very beneficial if we ever need to add more state, or change something about the underlying implementation, and not

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

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

Which optimization did you find unsafe? Thanks, --Serge ср, 21 авг. 2019 г. в 05:12, Cameron McInally <cameron.mcinally at nyu.edu>: > On Tue, Aug 20, 2019 at 1:02 PM Serge Pavlov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> During the review of https://reviews.llvm.org/D65997 >>

On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself. > So, the xforms in question should only be valid under Fast-Math conditions. We could

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

Hi, We are interesting in expanding some vector operations directly in the IR form as constants https://reviews.llvm.org/D33406, 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:

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

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_ absence of side effects and what promises we make to anyone using the 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

Do we really want to have fneg be the only instruction with guaranteed no side effects? That just sounds like a gotcha waiting to happen. Or it could result in horrible code depending on the architecture. I’m still leaning towards having both an intrinsic and an instruction, and if they happen to have the same behavior then that’s fine. If fneg is to be a special instruction with extra promises

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

It’s true, I am working on this. I have committed the initial patch to add constrained intrinsics for the basic FP operations. This has the desired effect of preventing optimizations that would violate strict FP semantics with regard to rounding mode and exception status, but it also prevents many safe optimizations. Later this year I’ll be going through the code base and trying to teach

Hi all, During the review of https://reviews.llvm.org/D65997 an issue was revealed, which relates to the decision of how compiler should represents constrained floating point operations. If a floating point operation requires rounding mode or exception behavior different from the default, it should be represented by constrained intrinsic (

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

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

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

I have no example side effects in hand. But LLVM targets a bunch of architectures, and who knows what the future holds. So it may be prudent to not promise too much so as to leave ourselves an escape hatch. Doesn’t LLVM target some chips that have floating point instruction sets that are not IEEE compliant? Can we be certain that no new LLVM target will ever have to jump through hoops to avoid

Hi all, I came across an issue caused by the Call-Graph Simplify Pass. Here is a a small repro: ``` define double @foo(double %a1, double %a2, double %a3) #0 { entry: %a_mul = fmul double %a1, %a2 %a_cmp = fcmp ogt double %a3, %a_mul br i1 %a_cmp, label %a.then, label %a.end a.then: %a_div = fdiv double %a_mul, %a3 br label %a.end a.end: %a_factor = phi double [ %a_div, %a.then ],