<div dir="ltr"><div><div><div>I need to read up on how nsw would make this different, but I see your point about the shift:<br><br>  %bf.result.shl = shl i8 %bf.value, 5<br>  %bf.result.ashr = ashr i8 %bf.result.shl, 5<br>
<br></div>This should have splatted the sign bit across the upper 5 bits of the char, so the subsequent compare:<br> %cmp = icmp slt i32 %bf.cast, 1<br><br></div>Can't be transformed to a check for 'equal to 0'.<br>
<br></div>Thanks!<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 9:18 PM, Henrique Santos <span dir="ltr"><<a href="mailto:henrique.nazare.santos@gmail.com" target="_blank">henrique.nazare.santos@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I actually think it is a problem with the optimizer like Kay first thought. -instcombine seems turning "((x and 6) shl 5) slt 32" into "(x and 6) slt 1". If the comparison were unsigned or the shl had a nsw flag, I think this would be okay. Since none of these is true, I don't think this transformation is correct.<span class="HOEnZb"><font color="#888888"><br>

<br></font></span></div><span class="HOEnZb"><font color="#888888"><div>H.<br></div></font></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 16, 2013 at 1:41 AM, Mark Lacey <span dir="ltr"><<a href="mailto:mark.lacey@apple.com" target="_blank">mark.lacey@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <<a href="mailto:kkhoo@perfwizard.com" target="_blank">kkhoo@perfwizard.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr">I've been diagnosing this bug:<br><a href="http://llvm.org/bugs/show_bug.cgi?id=17827" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17827</a><br><br>Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How do we fix this?<br>

</div></blockquote><div><br></div></div><div>I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int.</div>

<br><blockquote type="cite"><div><div dir="ltr">
<br><span style="font-family:courier new,monospace">$ cat bitfield.c</span><br><span style="font-family:courier new,monospace">/* %struct.S = type { i8, [3 x i8] } ??? */<br>struct S {<br>  int f0:3;<br>} a;<br><br>int foo (int p) {<br>


  struct S c = a;<br>  c.f0 = p & 6;<br>  return c.f0 < 1;<br>}<br><br>int main () {<br>  return foo (4);<br>}</span><br><br><br></div></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>