similar to: [LLVMdev] User defined types in LLVM-IR

Hi Arushi, > Given a LLVM bitcode file, is there any way of knowing which type declarations > actually came from the user code and what transformations were made by the front > end. not really. However debug info may give you some of the information you are looking for. Ciao, Duncan.

Hi, LLVM front end is taking a user defined type of [21 x { i32, i32, i32, [8 x i32] }] and converting it to the structurally equivalent type { { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32, i32, [8 x i32] }, { i32, i32,

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =

Hi, For a call like this, %tmp6 = call i32 (...)* bitcast (i32 (i8*, i8, i8**)* @ssplit to i32 (...)*)(i8* %tmp599, i32 46, i8** %domainv3) nounwind ; <i32> does the 2nd argument get zero extended or sign extended? Thanks, Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Apr 5, 2011 at 1:44 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi, > > > %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* >> (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* >> (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 >> ; >> <%struct.TypHeader*> [#uses=1]

Hi, 1. Does the alignment of the pointer returned by an AllocaInst depend on the instructions before it in the basic block? The 1st snippet below aligns 'a' correctly, while the 2nd one doesnt. (the method handle_args, only prints out the values of arguments, and returns argv unchanged). define i32 @main(i32 %argc, i8** %argv) nounwind { entry: %argc_addr = alloca i32

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

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 ;

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 =

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                

Hi, Is it correct to convert, %196 = load i32* %195, align 8 ; <i32> [#uses=1] %197 = zext i32 %196 to i64 ; <i64> [#uses=1] %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] %199 = add i64 %198, %197 ; <i64> [#uses=1] %200 = inttoptr i64 %199 to i8* ; <i8*>

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

Hi, > > Is it correct to convert, > > %196 = load i32* %195, align 8 ; <i32> [#uses=1] > %197 = zext i32 %196 to i64 ; <i64> [#uses=1] > %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] > %199 = add i64 %198, %197 ; <i64> [#uses=1] > %200 = inttoptr i64 %199 to i8*

%tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; <%struct.TypHeader*> [#uses=1] the 3rd parameter is now used in an srem statement. How do we know what value is used? Does this use decide whether the value is sign extended or zero

Hi Arushi, > %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* > (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* > (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; > <%struct.TypHeader*> [#uses=1] > > the 3rd parameter is now used in an srem statement. How do we know what value is > used? Does this use

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

On 4/20/11 10:08 AM, Jianzhou Zhao wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." I don't think the pointer aliasing rules

Unoptimized IR %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; <%struct.TypHeader*> [#uses=1] Optimized IR %tmp63 = call%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic (%struct.TypHeader* %tmp62, i64 %tmp24,

On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >