<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 23, 2017 at 5:59 AM, Garba Peter via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What you see here is a 1:1 translation of RISC-V assembler code into  C code.<br></blockquote><div>The built-in operator semantics apparently differ then between C and RISC-V assembler then.<br></div><div>Thus the "1:1 translation" needs to take that into account.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It may contain some obfuscations like shifting by negative amount but this I why I use compiler optimization to remove such patterns.<br></blockquote><div>An optimizing compiler operates on a program based on the semantics of the language (in this case, C).<br></div><div>Shifting by a negative amount is undefined behaviour in C.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
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.<br></blockquote><div>It does not sound like it is a bug. Either end (the input program or the compiler) can change.<br></div><div>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). <br></div><div>Perhaps a more pragmatic solution is to add functions in the input program which implement the RISC-V semantics in C (and call those).<br></div><div>You may also want to disable strict aliasing.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Peter<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: Tim Northover [mailto:<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.<wbr>com</a>]<br>
Sent: Samstag, 22. April 2017 20:23<br>
To: Garba Peter <<a href="mailto:peter.garba@gemalto.com">peter.garba@gemalto.com</a>><br>
Cc: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] LLVM Optimizations strange behavior/bug<br>
<br>
On 22 April 2017 at 04:18, Garba Peter via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Any idea if this is a bug or why clang does show this behavior ?<br>
<br>
The code is pretty rife with undefined behaviour. Casting a "char *"<br>
pointer to an "unsigned *" and dereferencing it violates strict aliasing (actually just doing the cast is dodgy, but usually not a problem in practice).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</span><span class="im HOEnZb">______________________________<wbr>__<br>
 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.<br>
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.<br>
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.<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>