similar to: [LLVMdev] SDIV >128bit, DAG->DAG error in LegalizeIntegerTypes

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

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

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

I saw something strange in the optimized LLVM code. It appears that sometimes an inlined function is optimized though the function itself is not optimized to the same level. Below is an example of an unoptimized/non-inlined function call: define void @_entry() uwtable { entry: %0 = call i64 @eval_expr() call void @trace_integer(i64 %0) ret void } 'eval_expr' is a big ugly series

Hi, I have a simple C case as following: int test(int x, int y) { return -x / -y; } With llvm-gcc -O1, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sub i32 0, %x ; <i32>:0 [#uses=1] sub i32 0, %y ; <i32>:1 [#uses=1] sdiv i32 %0, %1 ; <i32>:2 [#uses=1] ret i32 %2 } With llvm-gcc -O2, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sdiv i32

> 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

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

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,

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

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

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

Hi, On 24/02/13 06:48, edA-qa mort-ora-y wrote: > Which optimizer would remove duplicate, or unneeded loads? In my > generator I end up having a lot of the same load. For example here I > keep loading "@pt" which will always be the same value. in order to do this, the optimizers need to know that the call to @trace_integer does not modify the contents of @pt. Is it logically

Which optimizer would remove duplicate, or unneeded loads? In my generator I end up having a lot of the same load. For example here I keep loading "@pt" which will always be the same value. %16 = load %1** @pt, align 8 %17 = getelementptr inbounds %1* %16, i64 0, i32 2, i32 0 %18 = load i32* %17, align 4 call void @trace_integer(i32 %18) %19 = load %1** @pt, align 8 %20 =

> 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

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

On 04/25/2014 10:12 AM, Eric Christopher wrote: > Hi Andrew, > > Replying in both places because this mail is a pretty good summary of > issues and so it's worth replying to... my apologies for continuing in > both places. Responding to LLVMDev - I for one had missed this part of the thread. > >> The only language aspect under discussion is integer division. Every