[llvm-dev] opt -instcombine interesting behavior

[Nema, Ashutosh via llvm-dev]

Thanks for correcting Mehdi, its “the result is undefined” not “undefined behavior”.

Regards,
Ashutosh

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Monday, December 19, 2016 11:32 PM
To: Nema, Ashutosh <Ashutosh.Nema at amd.com>
Cc: Stephan Plöger <ploegers at cs.uni-bonn.de>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] opt -instcombine interesting behavior


On Dec 19, 2016, at 9:51 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

 %reg = alloca i32, i32 0
Allocating 0 bytes is legal but it's an undefined behavior, please refer:
http://llvm.org/docs/LangRef.html#id184

Nit: I believe that when LangRef says “the result is undefined”, it does not mean “undefined behavior”.
See http://llvm.org/docs/LangRef.html#undefined-values for more details.


You need to correct allocation to get the desired output, i.e.:

 %reg = alloca i32, i32 1

The “, i32 1” is optional though (default is 1).

—
Mehdi






Regards,
Ashutosh


-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Stephan Plöger via llvm-dev
Sent: Monday, December 19, 2016 10:11 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [llvm-dev] opt -instcombine interesting behavior

Hi all,

I've been playing around with the llvm optimizer and stumbled upon an
interesting behavior with respect to the "instcombine" option. I tried to
optimize the following small program (see also attachment small.ll) (only
with "instcombine"):

clang -v
clang version 4.0.0 (trunk 288238)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found
candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0 Found
candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6 Found candidate
GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0 Found candidate GCC
installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC
installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found
candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64


llvm-as small.ll -o small.bc
opt -instcombine small.bc -o smallOpt.bc


define i32 @main() {
 %reg = alloca i32, i32 0
 store i32 1, i32* %reg
 %1 = getelementptr i32, i32* %reg, i32 0
 %2 = bitcast i32* %1 to [4 x i8]*
 %3 = getelementptr [4 x i8], [4 x i8]* %2, i32 0, i32 1
 store i8 1, i8* %3
 %4 = load i32, i32* %reg
 ret i32 %4
}

The program in pseudo code would/should simplified look something like
this:

int main(){
   reg = 1;
   [reg+1] = 1; //Second byte of reg is set to 1
   return reg;
}

I assumed it would be optimized to - again pseudo code -:

int main(){
   return 257;
}

Instead, the program is optimized to(see also attachment
smallOpt.ll/smallOpt.bc):

define i32 @main() {
 ret i32 1
}

So i verified my assumption by printing '%4' of the original program
(smallPrint.ll/smallPrint.bc) and the output was 257.
I also optimized smallPrint.ll/smallPrint.bc , again only with instcombine, but
the output is changed to 1 (smallPrintOpt.bc).

I also tested it with clang 3.8.0.

What am i missing?


Best regards,
Stephan
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161220/808162da/attachment.html>