similar to: [LLVMdev] new LLVM IR features

Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] new LLVM IR features"

2009 Jul 29
0
[LLVMdev] new LLVM IR features
On Wednesday 29 July 2009 11:25, Dan Gohman wrote: > Getelementptr now has an optional flag: inbounds. WIth this flag, > if the result of a getelementptr is not in bounds of an allocated > object, > the result value is undefined. Note the the new getelementptr rule > applies regardless of whether the keyword is present. How do the semantics of "inbounds" differ from
2009 Jul 29
2
[LLVMdev] new LLVM IR features
On Jul 29, 2009, at 9:41 AM, David Greene wrote: > On Wednesday 29 July 2009 11:25, Dan Gohman wrote: > > >> Getelementptr now has an optional flag: inbounds. WIth this flag, >> >> if the result of a getelementptr is not in bounds of an allocated >> >> object, >> >> the result value is undefined. Note the the new getelementptr rule >>
2013 Nov 13
2
[LLVMdev] SCEV getMulExpr() not propagating Wrap flags
Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr
2015 Jun 11
4
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
[+Arnold] > On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > [+CC Andy] > >> Can anyone familiar with ScalarRevolution tell me whether this is an >> expected behavior or a bug? > > Assuming you're talking about 2*k, this is a bug. ScalarEvolution > should be able to prove that {0,+,4} is <nsw> and
2019 Aug 26
2
missing simplification in ScalarEvolution?
Hi Sanjoy, Thanks for the reply! Your approach sounds good to me! I think 1) is legal as address wraparound in unsigned range doesn't make sense given a positive offset, but I am not sure. I think umax will not be added if we can prove the predicate as known. I am not sure whether umax will get simplified if we add nuw to the expressions. -Pankaj -----Original Message----- From: Sanjoy
2013 Nov 02
0
[LLVMdev] SCEV and GEP NSW flag
On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Andy, et al., > > If I start with C code like this: > > void foo(long k, int * restrict a, int * restrict b, int * restrict c) { > if (k > 0) { > for (int i = 0; i < 2047; i++) { > a[i] = a[i + k] + b[i] * c[i]; > } > } > } > > Clang -O3 will produce code like
2013 Oct 31
2
[LLVMdev] SCEV and GEP NSW flag
Andy, et al., If I start with C code like this: void foo(long k, int * restrict a, int * restrict b, int * restrict c) { if (k > 0) { for (int i = 0; i < 2047; i++) { a[i] = a[i + k] + b[i] * c[i]; } } } Clang -O3 will produce code like this: entry: %cmp = icmp sgt i64 %k, 0 br i1 %cmp, label %for.body.preheader, label %if.end for.body.preheader: br label
2019 Aug 20
2
missing simplification in ScalarEvolution?
Hi, I have this small test case- %struct1 = type { i32, i32 } @glob_const = internal constant [4 x %struct1] [%struct1 { i32 4, i32 5 }, %struct1 { i32 8, i32 9 }, %struct1 { i32 16, i32 0 }, %struct1 { i32 32, i32 10 }], align 16 define void @foo() { entry: br label %loop loop: ; preds = %loop, %entry %iv = phi %struct1* [ getelementptr
2013 Nov 02
2
[LLVMdev] SCEV and GEP NSW flag
----- Original Message ----- > > On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Andy, et al., > > > > If I start with C code like this: > > > > void foo(long k, int * restrict a, int * restrict b, int * restrict > > c) { > > if (k > 0) { > > for (int i = 0; i < 2047; i++) { > > a[i] =
2019 Aug 21
2
missing simplification in ScalarEvolution?
Thanks for the suggestion but datalayout info did not solve the problem! -Pankaj -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Tuesday, August 20, 2019 5:26 PM To: Chawla, Pankaj <pankaj.chawla at intel.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] missing simplification in ScalarEvolution? Try adding a datalayout with pointer size
2020 Jun 10
2
LoopStrengthReduction generates false code
The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr
2014 Dec 26
3
[LLVMdev] Correct usage of `llvm.assume` for loop vectorization alignment?
Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I
2009 Jul 29
0
[LLVMdev] new LLVM IR features
On Wednesday 29 July 2009 13:25, Dan Gohman wrote: > The new GEP rule says that you can't dereference a pointer within an > object if it was computed from a GEP based on a different object. Ok. > The optional inbounds flag further constrains a GEP by saying that > the integer arithmetic implied by a GEP won't overflow. Then maybe it should be renamed. As I understand this,
2014 Feb 19
2
[LLVMdev] better code for IV
Hi Andrew, The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them. Thanks, Anat _____________________________________________ From: Shemer, Anat Sent: Tuesday, February 18, 2014 15:07 To: 'llvmdev at
2020 Jun 09
2
LoopStrengthReduction generates false code
Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,
2015 Jun 11
2
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
> On Jun 10, 2015, at 6:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > I'm not sure if inbounds can be used to prove <nuw>. If an object > %OBJ is allocated at address -1 then "gep inbounds %OBJ 1" is not > poison, but the underlying computation unsigned-overflows. I think that this should yield poison per langref because the signed
2020 Jun 09
2
LoopStrengthReduction generates false code
Hi. In my backend I get false code after using StrengthLoopReduction. In the generated code the loop index variable is multiplied by 8 (correct, everything is 64 bit aligned) to get an address offset, and the index variable is incremented by 1*8, which is not correct. It should be incremented by 1 only. The factor 8 appears again. I compared the debug output
2016 Oct 17
2
[SCEV] inconsistent operand ordering
Hi, I noticed an inconsistency in how ScalarEvolution orders instruction operands. This inconsistency can result in creation of separate (%a * %b) and (%b * %a) SCEVs as demonstrated by the example IR below (attached as gep-phi.ll)- target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" define void @foo(i8* nocapture %arr, i32 %n, i32* %A, i32* %B) local_unnamed_addr {
2018 May 24
0
gep and strength reduction
Hello, I was wondering if we had a way to strength reduce getelementptr today. For the following code: void func(float (&A)[132][140]) { > for (int i = 0; i < 132; ++i) > for (int j = 0; j < 140; ++j) > A[i][j] += 1; > } We will generate: (annotated with SCEV) define void @func([132 x [140 x float]]* nocapture dereferenceable(73920)) local_unnamed_addr #0 {
2015 Aug 22
2
loop unrolling introduces conditional branch
Thanks for your point that out. I just add DataLayout in my code such as "mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no luck. I'm really confused about this. Do I need to add more passes before -loop-unroll? On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 22, 2015, at 7:27 AM, Xiangyang