similar to: FW: clarification needed for the constrained fp implementation.

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,

I've recently been looking at how to implement in LLVM IR the rounding of floating point values when casting using different rounding modes and I've hit some problems. It seems that when casting down floats to less precise types the ``fptrunc`` LLVM IR instruction is used. The LLVM language reference suggests that it just truncates the value (which would be equivalent to rounding towards

Hi all, A question came up in a code review (https://reviews.llvm.org/D72820) about whether or not to allow fast-math flags to be applied to constrained floating point intrinsics (http://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics). This has come up several times before, but I don't think we've ever made a decision about it. By default, the optimizer assumes that

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

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

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

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

Howdy all, I've been playing around with programs that use the C11 fenv.h. It seems that, currently, the LLVM compiler does not regard to the exception-flag side-effects of floating point operations? When run on my macbook, the example code on http://en.cppreference.com/w/c/numeric/fenv/FE_exceptions does not print all the expected exceptions. Other examples: void foo() {

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

+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

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

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

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }

Hi all, Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if a function is called inside a region where FP environment differs from the default? If the function expects default FP mode it may work incorrectly in such case. The C2x standard draft ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4): Certain programming conventions support the intended

Hi, We are looking for new "Round Table" topics (i.e. mini-bof topics - formally known as hackers lab). The round table sessions are a great way for us all to discuss face-to-face any burning topics. We have scheduled a table after each BoF sessions so that people can follow up on those conversation-topics. We will also setup round tables during the event when there is interest (i.e.

I'm working on the #pragma STDC FENV_ACCESS ON support, specifically the support for a strict version of the FP to unsigned int conversion. I've got a pass that runs and converts a new intrinsic into code that uses the FP to signed int conversion code similar to how SelectionDAG handles this now. Except that SelectionDAG will let the target handle it if the target says it will. How do I,

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

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

On 04/12/2018 01:40 AM, p23 power via llvm-dev wrote: > Hi, > We are looking for new "Round Table" topics (i.e. mini-bof topics - > formally known as hackers lab).  The round table sessions are a great > way for us all to discuss face-to-face any burning topics. We have > scheduled a table after each BoF sessions so that people can follow up > on those