I'm in a situation where I have code that works fine if I don't run the instruction combining optimization pass, but breaks when I do. The code in question is meant to allocate space for two structs on the stack using alloca, and then pass pointers to these to a callee function. One struct serves to store the input to the function, the other serves for the callee function to write its output. This is part of my calling mechanism. Once the call is terminated, the caller will read from the output struct. The twist is that I am not allocating the structs directly, I am allocating buffers of bytes and casting the pointers into struct pointers. The following snipper is without instruction combining being run: %2 = alloca i8, i32 16 ; <i8*> [#uses=1] %3 = alloca i8, i32 12 ; <i8*> [#uses=1] %4 = call i8* @"Environment::extend"(i8* inttoptr (i32 173374432 to i8*)) ; <i8*> [#uses=3] %5 = call i8* @"ArrayObj::create"(i32 0) ; <i8*> [#uses=1] %6 = call i8* @"Interpreter::callFunction"(i8* inttoptr (i32 147457088 to i8*), i8* %5, i32 0) ; <i8*> [#uses=0] %7 = bitcast i8* %2 to { i64, i64 }* ; <{ i64, i64 }*> [#uses=3] %8 = bitcast i8* %3 to { i8*, i64 }* ; <{ i8*, i64 }*> [#uses=3] %9 = getelementptr { i64, i64 }* %7, i32 0, i32 0 ; <i64*> [#uses=1] store i64 25, i64* %9 %10 = getelementptr { i64, i64 }* %7, i32 0, i32 1 ; <i64*> [#uses=1] store i64 1, i64* %10 call void @fibonacci_0xa566d80({ i64, i64 }* %7, { i8*, i64 }* %8) %11 = getelementptr { i8*, i64 }* %8, i32 0, i32 1 ; <i64*> [#uses=1] %12 = load i64* %11 ; <i64> [#uses=1] %13 = icmp slt i64 %12, 1 ; <i1> [#uses=1] br i1 %13, label %21, label %14 As you can see, I allocate two structs, one taking 16 bytes (containing two i64 values), and one taking 12 bytes (containing a pointer and an i64 value, this is on a 32-bit machine). I then cast those pointers to the proper struct types (see values %7 and %8). I then call the fibonacci function, and after that, I read the i64 value of the second struct (see values %11, %12) and branch based on its value. This code works just fine when I run it. Now, if I run the instruction combining pass, the above code gets turned into this: %2 = alloca { i64, i64 }, align 8 ; <{ i64, i64 }*> [#uses=3] %3 = alloca [12 x i8], align 1 ; <[12 x i8]*> [#uses=3] %4 = call i8* @"Environment::extend"(i8* inttoptr (i32 148577248 to i8*)) ; <i8*> [#uses=3] %5 = call i8* @"ArrayObj::create"(i32 0) ; <i8*> [#uses=1] %6 = call i8* @"Interpreter::callFunction"(i8* inttoptr (i32 147883136 to i8*), i8* %5, i32 0) ; <i8*> [#uses=0] %7 = bitcast [12 x i8]* %3 to { i8*, i64 }* ; <{ i8*, i64 }*> [#uses=1] %8 = getelementptr { i64, i64 }* %2, i64 0, i32 0 ; <i64*> [#uses=1] store i64 25, i64* %8, align 8 %9 = getelementptr { i64, i64 }* %2, i64 0, i32 1 ; <i64*> [#uses=1] store i64 1, i64* %9, align 8 call void @fibonacci_0x8dc0d80({ i64, i64 }* %2, { i8*, i64 }* %7) %10 = getelementptr [12 x i8]* %3, i64 0, i64 8 ; <i8*> [#uses=1] %11 = bitcast i8* %10 to i64* ; <i64*> [#uses=1] %12 = load i64* %11 ; <i64> [#uses=1] %13 = icmp slt i64 %12, 1 ; <i1> [#uses=1] br i1 %13, label %21, label %14 This code does not work properly. If we take a look at value %10, we can see that it tries to read a value at offset 8! This is obviously wrong, as the value is an i64, and the size of the output struct is 12! Thus, the value should be read at offset 4, not 8! And here I find myself puzzled. I know the second struct really has size 12. I know the alignment is 4. Why is it that the instruction combining pass tries to read a value at offset 8, as if the pointer inside the output struct took 8 bytes? Furthermore, why does it allocate one struct as a struct, and one as a byte array? Is there a bug in this optimization pass, or am I doing something wrong? Note that I am using LLVM version 2.5. Any help would be appreciated! - Max -- View this message in context: http://www.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--tp24253572p24253572.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
Eli Friedman
2009-Jun-29 14:52 UTC
[LLVMdev] Instruction Combining Pass *Breaking* Struct Reads?
On Mon, Jun 29, 2009 at 5:54 AM, Nyx<mcheva at cs.mcgill.ca> wrote:> As you can see, I allocate two structs, one taking 16 bytes (containing two > i64 values), and one taking 12 bytes (containing a pointer and an i64 value, > this is on a 32-bit machine)Are you sure that's right? If the target data specifies that a pointer is 64 bits or that i64 has an alignment of 64 bits, this code is isn't allocating enough space for the struct. -Eli
I just found what the problem was. I was using a different target data for the optimization passes (creating a new one for the optimization passes) Not the target data from the execution engine... So the instruction combining pass was working with erroneous information, since by default it seems to assume pointers are 64 bits. Problem fixed! - Max Eli Friedman-2 wrote:> > On Mon, Jun 29, 2009 at 5:54 AM, Nyx<mcheva at cs.mcgill.ca> wrote: >> As you can see, I allocate two structs, one taking 16 bytes (containing >> two >> i64 values), and one taking 12 bytes (containing a pointer and an i64 >> value, >> this is on a 32-bit machine) > > Are you sure that's right? If the target data specifies that a > pointer is 64 bits or that i64 has an alignment of 64 bits, this code > is isn't allocating enough space for the struct. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- View this message in context: http://www.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--tp24253572p24256244.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
Seemingly Similar Threads
- [LLVMdev] Instruction Combining Pass *Breaking* Struct Reads?
- 10 commits - libswfdec/js libswfdec/swfdec_js_color.c libswfdec/swfdec_js_connection.c libswfdec/swfdec_js_movie.c libswfdec/swfdec_js_net_stream.c libswfdec/swfdec_js_video.c libswfdec/swfdec_js_xml.c libswfdec/swfdec_script.c player/.gitignore
- 4 commits - libswfdec/swfdec_asbroadcaster.c libswfdec/swfdec_as_frame.c libswfdec/swfdec_as_frame_internal.h libswfdec/swfdec_as_function.c libswfdec/swfdec_as_interpret.c test/trace
- 4 commits - libswfdec/swfdec_as_interpret.c test/trace
- [LLVMdev] Linking with C Library