similar to: [LLVMdev] A simple case about SDiv

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

Hi Duncan, Thanks for your help. But seems "opt -std-compile-opts" can't do this simplication :( Any ideas? Sheng. 2008/9/4 Duncan Sands <baldrick at free.fr> > > I tried several passes, like -instcombine, -simplifycfg, -gcse -globaldce > > -globalopt -adce , but all failed to do this transform. > > Try "opt -std-compile-opts

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

Hi llvm-dev, Looks like currently ScalarEvolution will give up if there is a sdiv in array subscript, e.g. int i; A[i * 64 / 2] in this case ScalarEvolution will just return an unknown for (i * 64 / 2). For this case, InstCombine will do the jobs, but in general, is there a pass to deal with the sdiv here? like replace sdiv by udiv based on the range of "i"? Thanks Hongbin

On Sat, 19 May 2007, Anton Korobeynikov wrote: >> * It seems that a C-call like printf("---\n") is transformed to puts >> ("---") in the LLVM IR instead of keeping it a printf. What are the >> circumstances in which this happens? Do other similar conversions >> occur? Can this be turned off (lower optimisation level?)? Manually >> replacing the

Hi Eli, Thanks. Do you mean ideally we should extend SimplifyIndVar to do the sdiv->udiv replacement? Thanks Hongbin On Wed, Mar 29, 2017 at 10:59 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/29/2017 10:35 AM, Hongbin Zheng via llvm-dev wrote: > >> Hi llvm-dev, >> >> Looks like currently ScalarEvolution will give up if there is a sdiv in

On Tue, 22 May 2007 23:52:46 -0700 (PDT) Chris Lattner <sabre at nondot.org> wrote: >On Sun, 20 May 2007, Bram Adams wrote: >> On a related note: while using llvmc I have some test cases where the >> following error now pops up on Linux X86 (not on OSX): >> >> <premain>: CommandLine Error: Argument 'debug' defined more than once! >> llvmc:

Hello, Bram > * It seems that a C-call like printf("---\n") is transformed to puts > ("---") in the LLVM IR instead of keeping it a printf. What are the > circumstances in which this happens? Do other similar conversions > occur? Can this be turned off (lower optimisation level?)? Manually > replacing the puts-calls by a printf-call is not

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

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: > > It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing also happens to zext <2 x i32> -> <2 x

On Wed, Mar 29, 2017 at 2:15 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/29/2017 1:05 PM, Hongbin Zheng wrote: > >> Hi Eli, >> >> Thanks. Do you mean ideally we should extend SimplifyIndVar to do the >> sdiv->udiv replacement? >> > > I haven't really looked into it closely, but it seems to make sense. Ok. Once I extend

Hi, I'm using pass ScalarEvolution to analyze the loop trip count on my application. And I found a possible bug in the code, that is in function SCEVAddRecExpr::getNumIterationsInRange(), Line 2905: 2904 // The exit value should be (End+A)/A. 2905 APInt ExitVal = (End + A).udiv(A); 2906 ConstantInt *ExitValue = ConstantInt::get(ExitVal); The divide should be sdiv, right?

On Mon, 20 Mar 2006, Michael McCracken wrote: > Hi, I'm trying to access an analysis pass from the Inliner pass, and > I'm having a lot of trouble getting that to work - I can verify that > my pass is loaded and run (it is a dynamically loaded pass that is > part of an analysisgroup), however, when I access it using > getAnalysis<> from within Inliner::runOnSCC, I am

It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing also happens to zext <2 x i32> -> <2 x i64> and trunc <2 x i64> -> <2 x i32>. Any ideas to optimize these

On 3/21/06, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 20 Mar 2006, Michael McCracken wrote: > > > Hi, I'm trying to access an analysis pass from the Inliner pass, and > > I'm having a lot of trouble getting that to work - I can verify that > > my pass is loaded and run (it is a dynamically loaded pass that is > > part of an analysisgroup),

------------------------------------ IR ------------------------------------------------------------------ if.then.i.i.i.i.i.i: ; preds = %if.then4 %S25_D = zext <2 x i32> %splatLDS17_D.splat to <2 x i64> %umul_with_overflow.i.iS26_D = shl <2 x i64> %S25_D, <i64 3, i64 3> %extumul_with_overflow.i.iS26_D = extractelement <2 x i64>

This snippet of IR is interesting: %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub.iS36_D, <i64 24, i64 24> %cmp10S38_D = icmp ugt <2 x i64> %sub.ptr.div.iS37_D, %splatInsMapS1_D.splat %zextS39_D = sext <2 x i1> %cmp10S38_D to <2 x i64> %BCS39_D = bitcast <2 x i64> %zextS39_D to i128 %mskS39_D = icmp ne i128 %BCS39_D, 0 br i1 %mskS39_D,

Hi, I'm trying to access an analysis pass from the Inliner pass, and I'm having a lot of trouble getting that to work - I can verify that my pass is loaded and run (it is a dynamically loaded pass that is part of an analysisgroup), however, when I access it using getAnalysis<> from within Inliner::runOnSCC, I am instead getting the default, dummy version of my analysis, which should

On 07/24/2015 03:42 AM, Benjamin Kramer wrote: >> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: >> >> It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing