[llvm-dev] LLVM Optimizations strange behavior/bug

[James Courtier-Dutton via llvm-dev]

On 23 April 2017 at 10:59, Garba Peter via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> What you see here is a 1:1 translation of RISC-V assembler code into  C code.
>
> It may contain some obfuscations like shifting by negative amount but this I why I use compiler optimization to remove such patterns.
> But with the provided sample clang/llvm seems to be too optimistic  with optimizations compare to GCC and CL and I really would like to
> get this one fixed to use the output LLVM IR for further optimization on the optimized code and get the same behavior as the other compilers.
>

a shift by a negative amount is probably OK, so long as you understand
the consequences.
E.g. For a lot of CPUs (e.g X86):
1(32bit) << 37 == 32
(What's happening is the shifter in the CPU just gets the low five bits.)
If you write this in C code, you would expect:
1(32bit) << 37 == 0

So, when representing that in C code.
You really need to represent it as:
1(32bit) << (37 & 0x1f) == 32   (Make the C representation equivalent
to the ASM instruction.)
Similarly, you would need to add the "AND" into the LLVM bitcode.

Kind Regards

James