similar to: FENV_ACCESS and floating point LibFunc calls

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

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

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

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep > from introducing additional observable side-effects, and it's clear that whatever did this did not account > for floating point exception. That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem. In

On 11 May 2017 at 18:30, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I note that on your bug that you have stated that the branch is faster than > the conditional move. Faster code is a side effect of the fix in this > particular case. On the contrary: the faster code is pretty much the only reason this can happen before the rest of the FENV support lands.

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

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 >

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

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 >

+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at

Hello, at the recent EuroLLVM developer meeting in Bristol I held a BoF session on the topic "Towards implementing #pragma STDC FENV_ACCESS". I've also had a number of follow-on discussions both on-site in Bristol and online since. This post is intended as a summary of my current understanding set of requirements and implementation details covering the overall topic. I'm

Hi Ulrich, I am interested in knowing if the current proposals also take into account the FP_CONTRACT pragma and the ability to implement options that imply a specific value for the FLT_EVAL_METHOD macro. Additionally, I am not aware of the IR being able to represent the potentially deferred loss of precision that the C language semantics provide; in particular, applying such semantics to the

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

On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > Hi Ulrich, > > I am interested in knowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for >

> 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

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

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,

On Wed, May 23, 2018 at 12:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > > Hi Ulrich, > > I am interested in knowing if the current proposals also take into account > the FP_CONTRACT pragma > > > We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is