[llvm-dev] opt -instcombine interesting behavior

[Mehdi Amini via llvm-dev]

> On Dec 19, 2016, at 9:51 AM, Nema, Ashutosh via llvm-dev <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 <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 <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
>> 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
> 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/20161219/f0b5cfe5/attachment.html>