similar to: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: > On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for > offering to help. I've had some other priorities that have > prevented

On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other priorities that have prevented me from making > progress on this recently. > > As far as I know, there is no support at all in clang for handling the >

On 8 Jan 2018 19:50, "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org> wrote: On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other

> 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

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some

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 currently dropping that information). I'm out of my depth on this transition, but I think maybe we could

On 9 Jan 2018 22:55, "John McCall via llvm-dev" <llvm-dev at lists.llvm.org> wrote: On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined

>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by

On Tue, Jan 09, 2018 at 06:53:51PM +0000, Kaylor, Andrew via cfe-dev 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 >

Oh, and other thing: Are you planning to attend the upcoming LLVM developer's meeting in Bristol? I thought it might be good idea to get all parties interested in this feature together in person, if we're at the same meeting anyway. So I was thinking of submitting a proposal for a BoF session on this topic ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich

I know next to nothing about the AST, so I'll leave commentary on that to someone who does except to say that I don't believe there is a strong connection between Richard's suggestion and Hal's. An IRBuilder can be created anywhere (and is frequently used in the optimizer). When the front end support is implemented it may use an IRBuilder that leverages the state Hal is suggesting,

Hi Andrew, sorry for the delay, I only now got some time to look into this a bit more. But I still have a number of questions of how to actually implement this in the back end. Looking at this bottom-up, starting with the behavior of the actual machine instructions, we have (at least on SystemZ) the following things to consider: A) Rounding mode Most FP arithmetic instructions use the

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the

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

On 11/03/2017 05:26 PM, 陳韋任 via llvm-dev wrote: > > > 2017-11-04 4:29 GMT+08:00 Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > > Copying the list on a discussion of potentially general interest…. > > *From:* Kaylor, Andrew > *Sent:* Friday, November 03, 2017 1:11 PM > *To:* 'Ding,

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

I'm working with Andrew on D43515 right now, and some of these unanswered questions are directly relevant to that patch. So.... On Fri, Feb 09, 2018 at 03:42:20PM +0100, Ulrich Weigand wrote: > C) Floating-point exceptions > If a mask bit in the floating-point status register is set, then all FP > instructions will *trap* whenever an IEEE exception condition is >

Hi all, Background I've been working on adding the necessary support to LLVM for clang to be able to support the STDC FENV_ACCESS pragma, which basically allows users to modify rounding mode at runtime and depend on the value of floating-point status flags or to unmask floating point exceptions without unexpected side effects. I've committed an initial patch (r293226) that adds

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set