search for: fenv_access

+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 this point during execution, > we will *always* have the default FP environme...

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

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 posting this here in the hope this can serve as a...

...y coarse-grained in that respect, but I admit to not being particularly informed in that space. If there is a good model for such dependencies, then I think it could be used to handle the strict/non-strict mixing. -- Hubert Tong, IBM PS A nitpick on wording: The idea of being inside or outside of FENV_ACCESS regions is instead be expressed in terms of the state of the FENV_ACCESS pragma within the C Standard. On Wed, May 23, 2018 at 10:48 AM, Ulrich Weigand via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > at the recent EuroLLVM developer meeting in Bristol I held a BoF &g...

...I admit to not being > particularly informed in that space. If there is a good model for such > dependencies, then I think it could be used to handle the > strict/non-strict mixing. > > -- Hubert Tong, IBM > > PS A nitpick on wording: The idea of being inside or outside of > FENV_ACCESS regions is instead be expressed in terms of the state of > the FENV_ACCESS pragma within the C Standard. > > On Wed, May 23, 2018 at 10:48 AM, Ulrich Weigand via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hello, > >...

...We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > I am not sure we have the same interpretation of what the FP_CONTRACT pragma does. Subclause 6.5 paragraph 8 of C11 implies (for example) that even where the FENV_ACCESS pragma is "on", folding a constant subexpression with an exactly representable result on an implementation where FLT_EVAL_METHOD is 0 is within the range of acceptable implementation-defined behaviour despite intermediate overflow under non-contracted evaluation. Which is to say that the...

..., but I'd like to start by getting input on whether everyone agrees with my judgment on how these things should work and whether I've missed anything. Here's what I've got. ====================== FP semantic modes ====================== except_behavior { ignore, strict, may_trap } fenv_access { on, off } rounding_mode { dynamic, tonearest, downward, upward, towardzero } contract { on, off, fast } denormal_fp_math { IEEE, PreserveSign, PositiveZero } denormal_fp32_math { IEEE, PreserveSign, PositiveZero } support_math_errno { on, off } no_honor_nans { on, off } no_honor_infinities { on,...

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

...tss2si %xmm0, %ecx movl $12, %eax cmoval %ecx, %eax retq On Thu, May 11, 2017 at 1:28 PM, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Michael, > > > > To be honest I haven’t started working on FP to integer conversions for > FENV_ACCESS yet. > > > > To some extent I would consider the issue that you found independent of > what I’m doing to constrain FP behavior. That is, I think we ought to make > the change you’re asking for even apart from the FENV_ACCESS work. When I > get to the conversions for FENV_ACCE...

...t; > I mentioned in my review comments that my work on this has been > motivated by the STDC pragmas, and I think if I explain that it > might make the semantics of the intrinsics seem a little more > natural. The primary pragma I have in mind here is the “STDC > FENV_ACCESS” pragma. I believe this is part of the C99 standard, > but compiler support for it is still mostly (if not entirely) > missing. For instance, if you try to use this pragma with clang > you will get a message telling you that the pragma isn’t supported > and it will hav...

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): Cer...

..., Clark <clark.nelson at intel.com>; Marcus Johnson <bumblebritches57 at gmail.com>; wei.ding2 at amd.com; llvm-dev <llvm-dev at lists.llvm.org>; Hal Finkel <hfinkel at anl.gov>; Bob Huemmer <bob.huemmer at sas.com> Subject: Re: [cfe-dev] [llvm-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 > <[1]llvm-dev at lists.llvm.org> wrote: > > Hi Kevin, > Thanks for reaching out about this, and thanks especially...

...branch, but I haven’t tried > it yet. > > > > As a side effect, which is what originally drew Michael’s attention to > this conversion, the INEXACT floating point flag is set even for exact > conversions as a result of the speculative FSUB. That’s how this got > related to FENV_ACCESS support. > > > > I don’t know if there has been a bug opened for this issue. There was an > earlier discussion here: https://groups.google.com/ > forum/#!topic/llvm-dev/Tl9SD-edUJI > > > > -Andy > > > > > > *From:* Sanjay Patel [mailto:spatel at rota...

...I'll say more about this in a minute. I mentioned in my review comments that my work on this has been motivated by the STDC pragmas, and I think if I explain that it might make the semantics of the intrinsics seem a little more natural. The primary pragma I have in mind here is the "STDC FENV_ACCESS" pragma. I believe this is part of the C99 standard, but compiler support for it is still mostly (if not entirely) missing. For instance, if you try to use this pragma with clang you will get a message telling you that the pragma isn't supported and it will have no other effect. We want...

...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 FENV_ACCESS pragma. I have a sample patch somewhere that I >> created to demonstrate how the front end would create the >> constrained intrinsics instead of normal FP operations, but >> correctly implementing support for the pragma requires more front >> end and language...

I'll give some data points from our OpenVMS Itanium (and Alpha) platforms where we support multiple IEEE modes and dynamic rounding in our C and Fortran compilers (we don't have actual FENV_ACCESS in our C product but you can come close). On the command line, you get to pick IEEE modes with:   /IEEE_MODE         /IEEE_MODE=option         /IEEE_MODE=DENORM_RESULTS (D)      Selects the IEEE floating-point mode to be used.      Options:       FAST              During program execution, on...

...> 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 > FENV_ACCESS pragma. I have a sample patch somewhere that I created to > demonstrate how the front end would create the constrained intrinsics > instead of normal FP operations, but correctly implementing support for the > pragma requires more front end and language expertise than I possess. I > bel...

...as.com>, "bumblebritches57 at gmail.com" <bumblebritches57 at gmail.com>, "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at lists.llvm.org> Date: 09.01.2018 19:55 Subject: RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported? 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 c...

Ulrich Weigand/Germany/IBM wrote on 06.03.2018 16:07:34: > So it appears to me that if we need a chain (or control register > dependencies etc.), it would be easier on the back-end anyway to > have a different ISD node, in which case it just might be the easiest > to pass the STRICT_ nodes through to the back-end if it wants ... > > I'll try and go ahead with the SystemZ

...; > 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 FENV_ACCESS pragma. I have a sample patch somewhere that I > created to demonstrate how the front end would create the > constrained intrinsics instead of normal FP operations, but > correctly implementing support for the pragma requires more front > end and language expertise than...