similar to: EuroLLVM Numerics issues

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

Hi Micheal, Thanks for the blog post. Just like to point out few things that I thought is related to FP Numerics. LLVM could do some additional transformation with "sqrt" and "division" under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long latency instructions and could get benefit if enabled under unsafe math. Also are we considering doing such FP

Hi, It’s been a few years now since I added some intrinsics for doing vector reductions. We’ve been using them exclusively on AArch64, and I’ve seen some traffic a while ago on list for other targets too. Sander did some work last year to refine the semantics after some discussion. Are we at the point where we can drop the “experimental” from the name? IMO all target should begin to transition

On Sep 15, 2014, at 4:17 PM, Owen Anderson <resistor at mac.com> wrote: > I’d be fine with that proposal. I could even be convinced if we wanted to add a pair of NaN-propagating intrinsics as well, for targets and languages that want those semantics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are

I don't think the global fast math flag should override the NoContraction decoration as that's mostly the point of that decoration to begin with, to have fine granular control while still having a broad sweeping optimization. Did I miss your point? I feel like I did. On Thu, Aug 23, 2018, 3:42 PM Michael Berg <michael_c_berg at apple.com> wrote: > Ryan, > > Given that the

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef: Follows the IEEE-754 semantics for minNum, which also

Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-propagating min and max, how about a compromise? We add intrinsics following the IEEE-754 semantics, but we also follow IEEE-754 (and ARMv8) in renaming them to minnum and maxnum, to clarify which interpretation these intrinsics are using. -------------- next part -------------- An HTML

Nicolai, Can you do without the use of -fp-contract=fast (Options.AllowFPOpFusion == FPOpFusion::Fast ) and without Unsafe? As I SPIR-V’s usage of NoContraction flies in the face of both. If so, you should be able to get what you want, as then you are down to just IR flags. You will need a model to generate the correct behavior though in your SPIR-V implementation wrt IR flag emissions.

Michael, >From the spec with regards to reassoc: – 15225 Include no re-association as a constraint required by the NoContraction Decoration. I don't see a solution given the situation where -fp-contract=fast and we want to contract. Furthermore, I think a 'nocontract' flag will allow the IR to be more readable in it's intention. The problem is you can have 2 fp arith

On Fri, Mar 29, 2019 at 5:51 PM Arsenault, Matthew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > A few things I’ve been thinking about: > > - Is anyone working on finishing the migration to using the new fneg > instruction? > > What did you have in mind? I was not aware that there is work pending. > - Controls for allowing and/or mandating denormal

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 >

Hi Amara, We also had some discussions on the SVE side of reductions on the main SVE thread, but this description is much more detailed than we had before. I don't want to discuss specifically about SVE, as the spec is not out yet, but I think we can cover a lot of ground until very close to SVE and do the final step when we get there. On 31 January 2017 at 17:27, Amara Emerson via

+cc Simon who's also interested in reductions for the any_true, all_true predicate vectors. On 31 January 2017 at 20:19, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Amara, > > We also had some discussions on the SVE side of reductions on the main > SVE thread, but this description is much more detailed than we had > before. > > I don't

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

On 1 February 2017 at 08:27, Renato Golin <renato.golin at linaro.org> wrote: > Sorry, I meant min/max + reduce, just like above. > > %sum = add <N x float>, <N x float> %a, <N x float> %b > %min = @llvm.minnum(<N x float> %sum) > %red = @llvm.reduce(%min, float %acc) No, this is wrong. I actually meant overriding the max/min intrinsics to take

Hi, I found issues with INDVARS <-> LSR passes interactions after https://reviews.llvm.org/rL346397. There were two main changes in this commit: 1. Previously we were propagating SCEV add expressions even if DefInst of exit value has hard uses inside the loop. After rL346397 we forbid propagation of SCEV add expressions if DefInst of exit value has hard use inside the loop. 2. Previously

We knew the day when we needed another FMF bit was coming back in: https://reviews.llvm.org/D39304 ...it was just a question of 'when'. :) I'm guessing that an FTZ bit won't be the last new bit needed if we consider permutations between strict FP and fast-math. Even without that, denormals-as-zero (DAZ) might also be useful? So rather than continuing to carve these out bit-by-bit,

> ... math errno ... I wouldn't recommend to anyone that they should rely on math errno (because I don't trust libraries to correctly support it). My goal here was to incorporate our existing support for it into the rest of what I'm trying to document. My understanding is that for clang this primarily controls whether or not we feel free to substitute intrinsics for recognized

Hi, I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, but we've already used up the 7 bits available in Value::SubclassOptionalData (the "backing storage" for FPMathOperator::getFastMathFlags()). These are the possibilities I can think of: 1. Increase the size of FPMathOperator. This gives us some additional bits for FTZ and other fastmath flags we'd want

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