similar to: [LLVMdev] [llvm] r206732 - Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN,

Hi, I’d like to propose to extend LLVM IR intrinsics set, adding new ones for safe-division. There are intrinsics for detecting overflow errors, like sadd.with.overflow, and the intrinsics I’m proposing will augment this set. The new intrinsics will return a structure with two elements according to the following rules: safe.[us]div(x,0) = safe.[us]rem(x,0) = {0, 1} safe.sdiv(min<T>, -1) =

On April 25, 2014 at 9:52:35 AM, Eric Christopher (echristo at gmail.com) wrote: Hi Michael, > I’d like to propose to extend LLVM IR intrinsics set, adding new ones for > safe-division. There are intrinsics for detecting overflow errors, like > sadd.with.overflow, and the intrinsics I’m proposing will augment this set. > > The new intrinsics will return a structure with two

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, July 16, 2015 1:00:05 AM > Subject: Re: [LLVMdev] [RFC] Defining Infinite Loops > > > FWIW, I'm very much in favor of having a firm and clear answer

Hello everyone, The topic of whether or not LLVM allows for infinite loops has come up a lot recently (several times this week already). Regarding motivation, there are two important facts: 1. Some languages, such as Java, have well-defined infinite loops. See: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.9 and:

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, July 16, 2015 2:33:21 AM > Subject: Re: [LLVMdev] [RFC] Defining Infinite Loops > > > > > On Thu, Jul 16, 2015 at 12:27 AM Hal Finkel

Dear all! I'd like to do multiple imputation of missing values with s-plus libraries that are provided by Shafer (http://www.stat.psu.edu/~jls/misoftwa.html). I wonder, whether these libraries are compatible or somehow convertible to R (because I don't have S-plus), so that I can use this functions using the R Program. I would be happy if you could tell me, -if it is possible to use

Greetings folks, Shafer's S-plus package "norm" for multiple imputation of missing values in multivariate normal data has been most kindly and usefully ported to R by Alvaro A. Novo. Shafer's website http://www.stat.psu.edu/~jls/ lists four S-plus packages in all: NORM - multiple imputation of multivariate continuous data CAT - multiple imputation of multivariate

On 04/25/2014 02:21 PM, Eric Christopher wrote: >> In short, I agree with your observations that these intrinsics are not an >> obvious slam-dunk compared to making the explicit control flow, but I think >> that the intrinsics do give enough flexibility on the LLVM side that it >> would be great if front-ends used them rather than rolling the control flow >>

Introduction: We would like to add new keyword to 'sdiv'\'udiv' instructions i.e. 'no-overflow'. This is the updated solution devised in the discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118257.html The proposed keywords: "nof" stands for 'no-overflow' Syntax: <result> = sdiv nof <ty> <op1>,

I am very much in favor of having a div instruction with well defined div-by-zero and overflow behavior. The undefined behavior on certain values for LLVM intrinsics has been a major pain point for us in Julia, because adding the extra branches just kills performance and we know that there is an X86 instruction that just does what we want. Anyway, this was brought up briefly above, but want to

On May 2, 2014, at 4:25 PM, Philip Reames <listmail at philipreames.com> wrote: > > I'm still not happy with hiding the explicit control flow, but I can achieve the same effect as: > if( div by zero ) throw > (r, o, d) = safe.div(a,b); > if( o ) { > r = a; > } > > i.e. emit a separate guard branch for the interesting condition and not utilize the value

On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only makes sense for C and its very direct relatives.  The amount of control flow necessary to represent a safe division for any other language is ghastly.  (a/b) becomes something like (b != 0 ? ((a != INT_MIN ||

On April 25, 2014 at 1:44:37 PM, Reid Kleckner (rnk at google.com) wrote: Thanks for the writeup! It's very helpful. On Fri, Apr 25, 2014 at 11:49 AM, Filip Pizlo <fpizlo at apple.com> wrote: On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only

As the discussion has progressed and I've spent more time thinking about the topic, I find myself less and less enthused about the current proposal. I'm in full support of having idiomatic ways to express safe division, but I'm starting to doubt that using an intrinsic is the right way at the moment. One case I find myself thinking about is how one would combine profiling

On 05/02/2014 11:57 AM, Filip Pizlo wrote: > > On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com > <mailto:echristo at gmail.com>) wrote: > >> On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames >> <listmail at philipreames.com> wrote: >> > Andy - If you're not already following this closely, please start. >> We've

> I tried several passes, like -instcombine, -simplifycfg, -gcse -globaldce > -globalopt -adce , but all failed to do this transform. Try "opt -std-compile-opts -debug-pass=Arguments" If that does the simplification, then try bisecting the set of passes it ran (printed thanks to -debug-pass) to find out which combination did it. Ciao, Duncan.

> Any ideas? Most likely it is the gcc folder doing it. This gcc optimization is run in llvm-gcc because it's basically impossible to turn it off! You can check by passing -mllvm -disable-llvm-optzns to llvm-gcc along with -O2. If the optimization still occurs then it was gcc that did it. Ciao, Duncan.

Hello, > eh... I got some error as following: > llvm-gcc -O2 -mllvm -disable-llvm-optzns -emit-llvm -c test.c -o test.ll -S You need to pass these pair of options directly to cc1, driver is breaking them. -- WBR, Anton Korobeynikov

Hi, >Hello, > >> eh... I got some error as following: >> llvm-gcc -O2 -mllvm -disable-llvm-optzns -emit-llvm -c test.c -o >test.ll -S >You need to pass these pair of options directly to cc1, driver is >breaking them. Yes, you are right. Thanks for pointing out that. Sheng. >-- >WBR, Anton Korobeynikov -------------- next part -------------- An HTML

I'm getting the following error when trying to SDIV integers greater than 128bit (on an AMD64 target). LegalizeIntegerTypes.cpp:2047: void llvm::DAGTypeLegalizer::ExpandIntRes_SDIV(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SDIV!"' failed. Stack dump: 0. Running pass 'X86 DAG->DAG