<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/11/18 6:51 PM, Doerfert, Johannes Rudolf via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:20181212005142.GD1168@arch-linux-jd">
<pre class="moz-quote-pre" wrap="">Hi,

in a recent review [0], Florian Hahn helped me to realize something that
was rather surprising to me:

  The widely popular and very useful function
  llvm::Value::stripPointerCasts() can return a value with a different
  bit pattern than the input.

Now, I think this should not be the case but I want the hear other
opinions. Before I go on, please not that there is at least one location
in the code base [1] that makes a wrong assumption about the bit pattern
preservation.</pre>
</blockquote>
<p>If there's really only one place that gets this wrong (or only a few), I'm inclined to suggest option (1) below and fix this one place.<br>
</p>
<p>Matt, any thoughts on this?<br>
</p>
<p> -Hal<br>
</p>
<blockquote type="cite" cite="mid:20181212005142.GD1168@arch-linux-jd">
<pre class="moz-quote-pre" wrap="">


The Problem
-----------

StripPointerCasts will peel of address space casts but these can
potentially change the bit pattern.

Possible Solutions
------------------

1) Make stripPointerCasts not look through address space casts. A new
function (or parameter) would then be introduced to do the same thing
_and_ peel of address space casts.

2) Keep looking through address space casts in stripPointerCasts. A new
function (or parameter) would then be introduced to do the same but with
the guarantee that the bit pattern is preserved.
 

Note that the module implementation of stripPointerCasts and friends
makes basically all the changes to them easy.

Solution one has the benefit that our code is "more sound" than before
because the stripPointerCasts function is more restrictive. We might
lose performance though. Solution two will not disturb any existing code
but we might need to revisit the uses of stripPointerCasts to fix
existing bugs.


Suggestions welcome!

Thanks,
  Johannes


[0] <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D54956?vs=on&id=175572&whitespace=ignore-most#inline-485807">https://reviews.llvm.org/D54956?vs=on&id=175572&whitespace=ignore-most#inline-485807</a>

[1] LazyValueInfo::getPredicateAt() line ~1714, isKnownNull(...) is used
    after the stripPointerCasts() function might have changed the bit
    pattern (and thereby the null-ness).


</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>