[llvm-dev] LLVM Optimizations strange behavior/bug

[Hubert Tong via llvm-dev]

On Sun, Apr 23, 2017 at 5:59 AM, 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.
>
The built-in operator semantics apparently differ then between C and RISC-V
assembler then.
Thus the "1:1 translation" needs to take that into account.


>
> It may contain some obfuscations like shifting by negative amount but this
> I why I use compiler optimization to remove such patterns.
>
An optimizing compiler operates on a program based on the semantics of the
language (in this case, C).
Shifting by a negative amount is undefined behaviour in C.


> 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.
>
It does not sound like it is a bug. Either end (the input program or the
compiler) can change.
You may want the compiler to change (in which case, you may want to explore
implementing options/modes which "fix" the semantics of certain cases of
undefined behaviour).
Perhaps a more pragmatic solution is to add functions in the input program
which implement the RISC-V semantics in C (and call those).
You may also want to disable strict aliasing.


>
> Thanks,
> Peter
>
> -----Original Message-----
> From: Tim Northover [mailto:t.p.northover at gmail.com]
> Sent: Samstag, 22. April 2017 20:23
> To: Garba Peter <peter.garba at gemalto.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] LLVM Optimizations strange behavior/bug
>
> On 22 April 2017 at 04:18, Garba Peter via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > Any idea if this is a bug or why clang does show this behavior ?
>
> The code is pretty rife with undefined behaviour. Casting a "char *"
> pointer to an "unsigned *" and dereferencing it violates strict aliasing
> (actually just doing the cast is dodgy, but usually not a problem in
> practice).
>
> When I change those lines to use memcpy instead and compile with
> -fsanitize=undefined, apparently 4 of the shift operations are shifting by
> a negative amount (also undefined behaviour). I expect Clang is marking
> those as undef and simplifying everything down to a constant based on that.
>
> Certainly I start getting non-constant results when I fix those. Also,
> beware that shifting a signed int is only valid if the input is positive
> and the result is still fits, and you can only shift from 0 to the 1 less
> than the bit-width of the type. Generally you almost always want to do
> bitwise fiddling on unsigned quantities because of that first one.
>
> Cheers.
>
> Tim.
> ________________________________
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
> _______________________________________________
> 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/20170423/eea76963/attachment.html>