Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] GVN Infinite loop"
2011 May 04
0
[LLVMdev] GVN Infinite loop
On May 3, 2011, at 3:25 PM, Arushi Aggarwal wrote:
> Hi,
>
> GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either.
>
> Any pointers to how to reduce the test case.
Bugzilla can reduce testcases that cause infinite loops (it has a -timeout flag), I'd try it. Even if this doesn't
2011 May 03
3
[LLVMdev] GVN Infinite loop
Hi,
GVN seems to be running in an infinite loop on my example. I have attached
the output of one iteration. I cant seem to reduce the testcase either.
Any pointers to how to reduce the test case.
THanks,
Arushi
GVN iteration: 8
GVN WIDENED LOAD: %0 = load i8* getelementptr inbounds
(%struct.CHESS_POSITION* @search, i64 0, i32 23), align 2, !dbg !875
TO: %1 = load i16* bitcast (i8*
2016 Jun 30
0
Optimizations hindered by GVN widening
Currently, the GVN optimization widens loads if the alignment permits it. There are some limitations that show up, as seen in example below:
Initial IR:
declare void @consume(i8) readonly
define i8 @bar(i8* align 2 %a) {
%1 = load i8, i8* %a
%idx = getelementptr i8, i8* %a, i64 1
%2 = load i8, i8* %idx, align 1
call void @consume(i8 %1).
ret i8 %2
}
define i1 @foo(i8* %a) {
entry:
2011 Feb 24
1
[LLVMdev] Get Element Ptr inst
Thanks John. You are right.
Is this also true for constant GEP expressions? Do they also create a
pointer to the calculated type? The language manual does not state so
explicitly.
Arushi
On Thu, Feb 24, 2011 at 10:47 AM, John Criswell <criswell at illinois.edu>wrote:
> On 2/24/11 10:39 AM, Arushi Aggarwal wrote:
>
>> Given 2 GEPs as follows,
>>
>> %tmp124 =
2011 Feb 24
0
[LLVMdev] Get Element Ptr inst
On 2/24/11 10:39 AM, Arushi Aggarwal wrote:
> Given 2 GEPs as follows,
>
> %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0,
> i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1]
> %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0,
> !dbg !1051 ; <i16*> [#uses=1]
>
> can I replace the 2nd one with
>
> %tmp126 = getelementptr
2010 Apr 21
0
[LLVMdev] Function pointers bitcasted to varargs
Do you compile this as C? In C, unlike in C++, empty parenthesis do
not mean "no arguments", they mean "no prototype", which is typically
treated the same way as varargs in calling conventions. To declare
function with no arguments do typedef void (*FP)(void);
Eugene
On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
> Hi all,
>
>
2015 Aug 07
2
load instruction erroneously removed by GVN
Hi,
I'm having a problem with GVN removing a load instruction that I think
is needed.
Dump before GVN:
*** IR Dump Before Global Value Numbering ***
; Function Attrs: minsize optsize
define i16 @TEST__MAIN(i16 %argc.13.par, i16** %argv.14.par) #0 {
%buf.17 = alloca [10 x i16], align 1
%_tmp30 = getelementptr inbounds [10 x i16], [10 x i16]* %buf.17, i16
0, i16 0, !dbg !22
call
2010 Dec 13
1
[LLVMdev] How can I determine safely if a CallSite is "live" in a DSGraphs context
Hi,
I believe shouldHaveNodeForValue() should return false for
ConstantPointerNullValue.
Fixed in r121707.
Arushi
On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit
<kevin.streit at googlemail.com>wrote:
> I'm using BUDataStructures... But I tried LocalDatastructures and it didn't
> work either...
> On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at
2016 Jul 20
2
load instruction erroneously removed by GVN v2
Hello to whom this may concern,
Versioned this as I saw identical title before. I'm compiling a clang
project where I'm seeing GVN mess up and replace a load with a wrong def
value. I am using LLVM-3.5, but the problem has been observed upto 3.8.
To illustrate the problem,
define i32 @main
scalar.ph:
<initialize [80 x i16] %dest>
...
preheader:
%index=0
br test, loop1, bb2
2016 Sep 29
2
Load combine pass
> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> Hi Artur,
>
> Artur Pilipenko via llvm-dev wrote:
> > One of the arguments for doing this earlier is inline cost
> > perception of the original pattern. Reading i32/i64 by bytes look much
> > more expensive than it is and can prevent inlining of interesting
> >
2016 Jul 20
2
load instruction erroneously removed by GVN v2
Thanks for quick reply Daniel,
I tried to make a simple C testcase, but could not reproduce the same
condition with output from Clang. I suppose I could modify the C code to
make it look similar with TBAA's; I may be able to provide this by eod.
> store %ptr above the load.
My mistake; I was referring to the store $lcssa in bb2. Looking at the C
source code, it should definitely alias
2011 Feb 24
2
[LLVMdev] Get Element Ptr inst
Given 2 GEPs as follows,
%tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5,
!dbg !1051 ; <[2 x i16]*> [#uses=1]
%tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, !dbg
!1051 ; <i16*> [#uses=1]
can I replace the 2nd one with
%tmp126 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5,
i64 0, i64 0 ; <i16*>
When I try to
2011 Feb 22
0
[LLVMdev] Clone a function and change signature
On 2/22/11 1:31 PM, Arushi Aggarwal wrote:
> Hi,
>
> I want to clone a given function, and add an argument to it. I then
> want to add a call to that new function. I have a callInstruction CI,
> which I want to transform to call this new function, and to take a new
> argument.
If I understand correctly, you're cloning the function first and then
adding a new argument to
2016 Jul 20
2
load instruction erroneously removed by GVN v2
before inlining
all 20005
after inlining
somewhere here changed made it NoAlias
after Global Variable Optimizer
20014
20373 20255
20372 20254
before GVN
19993
20011 19991
20010 20030
It appears that TBAA metadata certainly changed after inlining and
subsequent passes. I have attached the .bc file. I think I will try to dump
out more TBAA metadata between passes. The method in
2011 Feb 23
0
[LLVMdev] LLVMdev Digest, Vol 80, Issue 37-Help to unsubscribe
Please unsubscribe me from this list.
Sujatha Gurumurthy
Staffing Consultant/Talent Advisor
UMG - Ultra Mobile Group
sujatha.gurumurthy at intel.com
US ERP Manager
Interested in Employee Referral Program
Visit referral.intel.com/
Intel USA Employee Referral Program Group
100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE
-----Original Message-----
From: llvmdev-bounces at
2010 Apr 21
2
[LLVMdev] Function pointers bitcasted to varargs
Hi all,
I had the following function that used function pointers with void arguments,
typedef void (*FP)();
void foo() {
printf("hello world from foo\n");
}
int main() {
FP fp;
fp = foo;
(*fp)();
}
The corresponding bitcode, with no optimizations is
target datalayout =
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
This code is generated for va_arg.
%6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**>
[#uses=1]
%7 = load i8** %6, align 8 ; <i8*> [#uses=1]
%8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0
; <%struct.__va_list_tag*> [#uses=1]
%9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;
2016 Sep 28
4
Load combine pass
One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function.
Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other
2011 May 12
0
[LLVMdev] Machine Function Pass
On 5/12/11 11:46 AM, Arushi Aggarwal wrote:
> I tried
> llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so
> --help
>
> But this does not show my pass. It says it is an unknown command line argument.
I'm assuming you've looked at other MachineFunctionPass'es and have
registered yours in the same way that they do. I don't think
2017 Jan 13
4
Wrong code bug after GVN/PRE?
Hi,
I've stumbled upon a case where I think gvn does a bad (wrong)
optimization. It's a bit messy to debug though so I'm not sure if I
should just write a PR about it a let someone who knows the code look at
it instead.
Anyway, for the bug to trigger I need to run the following passes in the
same opt invocation:
-sroa -instcombine -simplifycfg -instcombine -gvn
The problem