similar to: [LLVMdev] max/min intrinsics

On Dec 5, 2012, at 8:26 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > I have been working on a patch to add support for max/min reductions in LoopVectorize. One of the comments that came up in review is that the implementation could be simplified (and less fragile) if max and min intrinsics were recognized rather than looking for compare-select sequences. > >

declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> ) declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> ) declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8

Hi, I’d like to re-propose adding intrinsics for fmin / fmax. These can be used to implement the equivalent libm functions as defined in C99 and OpenCL, which R600 and AArch64 at least have instructions with the same semantics. This is not equivalent to a simple fcmp + select due to its handling of NaNs. This has been proposed before, but never delivered

Full_Name: Christian Marquardt Version: 2.1.0 OS: Linux (Redhat 9) Submission from: (NULL) (151.170.240.10) Following the advice of a reader of R-help, I would now like to submit this as a bug report: Say we have x = seq(1,3, by = 0.01) y = exp(x) Plotting and reversing linear axis is fine plot(x,y) plot(x,y, ylim = c(30,1)) as is a usual log-plot: plot(x,y, log =

… actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations). So I think your proposed semantics are perfectly

This is a problem with all floating point folding, not just with these operations. What Matt is proposing is consistent with how we fold other libm intrinsics. —Owen > On Aug 18, 2014, at 1:22 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > Wouldn’t it be better to use the target’s implementation (if there is one)

Hi Carter, I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations: - IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs - C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b What you’re proposing does not match any existing languages

I'm interested in using @llvm.experimental.vector.reduce.smax/umax to implement runtime overflow checking for vectors. Here's an example checked addition, without vectors, and then I'll follow the example with what I would do for checked addition with vectors. Frontend code (zig): export fn entry() void { var a: i32 = 1; var b: i32 = 2; var x = a + b; } LLVM IR code:

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

Good morning, I am currently displaying a time series with the time on the Y axis, and the values on the X axis. The problem is that I wanted to reverse the Y axis (that is, to have the latest date the closest to the X axis). So I looked for a way to do this on this mailing list and I found a response: inverting the ylim parameter of the plot. I did it, the data are displayed correctly, but now

The IR update to allow vector types was here: https://reviews.llvm.org/D57090 ...we didn't update the docs at that time because it was not clear what the backend would do with that, but that might've changed with some of the more recent patches. On Sat, Feb 9, 2019 at 1:42 AM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't think I understand your

Dear list, Could you please tell me the values of the minimum and maximum cutoff frequencies for each coding version of the 44.1 kHz sampled data? For instance, are the values fmin=100 Hz and fmax=12 kHz valid? Thank you very much in advance. Kind regards, ? Fernando A. Marengo Rodriguez, PhD Post-doctoral fellow on Acoustics and Beamforming -- Laboratory of Noise and Vibration (LVA) Federal

Hi all, I wish to draw 2 hist (or barplot) on the same graph. I can do it simply by using par(new=TRUE) , but it overlap with the first drawn, how to tell R to put in front of the graph the min value of the two graph in order for it to be seen and don't hide each other. I've been looking at help for barplot or hist but didn't find anything... (or my english is too poor to

Hi George, Have you considered changing our existing behavior to match GCC's builtin_object_size instead of adding a new parameter? That may be simpler overall. There's also a clear upgrade strategy -- fold every old style call to "<min> ? 0 : 1". You probably already know this, but GCC folds builtin_object_size(0, 0) to -1 and builtin_object_size(0, 2) to 0. We'll

Maybe we can have two versions of the intrinsic function, "ordered" and "unordered", just like fcmp has [1]. Would that work ? [1] - http://llvm.org/docs/LangRef.html#fcmp-instruction On Dec 17, 2012, at 11:14 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com]

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

At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. Yes, that's the obvious alternative. I don't think we have any strong opinion either way, and fcmp/select is certainly easier to implement. -- Kevin Schoedel, Software Developer,

Hi all, I would like to set up an iterative read & write sequence to avoid reading and writing each file one at a time. Hundreds of data sets to re-calculate.? The code I have works well individually, but would like to set up an iterative read, calculate and write changing the input and output file names each iteration. I? think I have read that there is an R? feature using

> On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > > More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing. Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. > > The IEEE version can also be