<div dir="auto"><div>Thanks Tim,<div dir="auto">I think I'll go for getZExtValue as you suggested. Anyway saw also getBoolValue that I can use.</div><div dir="auto"><br></div><div dir="auto">Thanks again for your help</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019, 09:32 Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 22 Mar 2019 at 08:09, Alberto Barbaro via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Now I would like to understand if the comparison was true or false. Is it correct to use condition.IntVal.getSExtValue() and if the value is 0 consider the true and if the value is -1 consider the condition false?<br>
<br>
The result of an icmp is a 1-bit integer. As a pure bag-of-bits 0b0 is<br>
false and 0b1 is true. If you interpret those as signed integers then<br>
0b1 is actually -1 though, so the condition is reversed from what you<br>
said above.<br>
<br>
It would probably be more natural if you used getZExtValue, which<br>
zero-extends the 1-bit answer and gives the much more natural result<br>
that 0 == false, 1 == true.<br>
<br>
> I'm not sure because I was expecting something different and I'm a bit lost<br>
<br>
I assume you were expecting 0 or 1 and aren't sure how to interpret<br>
the -1? It's really just a quirk of 2s-complement representation LLVM<br>
uses (together with most CPUs) that a 1-bit signed value doesn't<br>
actually have any positive values and the single non-zero one is -1.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div></div></div>