similar to: [RFC] Optional parameter tuples

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

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

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

Hello everyone, I've just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a could of new token types to be used with constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question. I would like some general feedback on the way I am proposing to use token arguments

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

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

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

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

On 11/6/20 8:49 AM, Roger Ferrer Ibáñez wrote: Hi Sjoerd, Trying to remember how everything fits together here, but could get.active.lane.mask not create the %mask of the VP intrinsics? Or in other words, in the vectoriser, who's producing the %mask and %evl that is consumed by the VP intrinsics? I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine

On 11/6/20 12:39 PM, Sjoerd Meijer wrote: Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq

Hi everyone, Sergey (CC’ed) worked on a series of patches to add support for floating-point environment and floating-point rounding modes in LLVM. This started *in 2014* and the patches after multiple rounds of review in the last months (involving amongst other Steve Canon, Hal Finkel, David Majnemer, and myself) are getting very close (IMO) to be in a state where we can land them. This is the

Hi Chandler, This scheme has significant advantages over what was being pursued, but one question (or two)... Under the proposed system, how would you represent the necessary dependency edges between the fp intrinsics and function calls? How is the state 'returned' to the caller? [I was thinking that our new operand bundles could help for the inputs, but the outputs? Plus what about the

Hi, I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 13:32 To: Sjoerd Meijer <Sjoerd.Meijer at

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, February 5, 2016 4:36:54 PM > Subject: Re: [llvm-dev] [RFC] FP Environment and Rounding mode

For RISC-V V and VE being explicit about %evl is important for performance & correctness and that is what VP does. The get.active.lane.mask intrinsic is used as a hint for the MVE, SVE backends to use hardware tail-predication (the backends reverse engineer that hint by pattern matching for get.active.lane.mask in the mask parameter of "some" masked intrinsics). IMHO, it's more

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for 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

FWIW, +1 from me. Just one request on the implementation though. However we model these intrinsics and their properties (metadata, constants, etc), can we please abstract away those details the same way we have MemCpyInst which just wraps an IntrinsicInst? I think this would be very beneficial if we ever need to add more state, or change something about the underlying implementation, and not

On 2/2/19 1:39 AM, Luke Kenneth Casson Leighton wrote: > > > On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de > <mailto:moll at cs.uni-saarland.de>> wrote: > > We could untie the mask length from the data length: > >   %result = call <scalable 4 x float> > @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4