<div dir="ltr"><div>Hi Ralf,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021 at 5:22 PM Ralf Jung <<a href="mailto:jung@mpi-sws.org">jung@mpi-sws.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 1. Forbidding arithmetic and bitwise operations in b<N> seems pointless. Just <br>
> define them as the corresponding i<N> op plus the union of provenance of the <br>
> operands. This allows consistent implementation of char/unsigned char as b8, <br>
> without having to jump back and forth between b8 and i8 all the time.<br>
<br>
FWIW, "char" addition happens at "int" type due to integer promotion. So there <br>
is no problem with back and forth here.<br>
<br>
"Union" of provenance is currently not an operation that is required to model <br>
LLVM IR, so your proposal would necessitate adding such a concept. It'll be <br>
interesting to figure out how "getelementptr inbounds" behaves on <br>
multi-provenance pointers...<br></blockquote><div><br></div><div>True, something needs to be said about that. The main question is whether "jumping" between different objects that are both in the provenance set is poison or not. Ultimately, the goal of provenance is to help alias analysis, so that's what should be driving that choice.<br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 6. (How) are pointer types fundamentally different from b<N> types of the <br>
> correct size? (By this I mean: is there any interesting difference in the values <br>
> that these types can carry? Ignore surface differences like the fact that GEP <br>
> traditionally goes with pointers while `add` goes with integer types -- we could <br>
> have a GEP instruction on a correctly sized b<N>)<br>
<br>
I'm not saying I have the answer here, but one possible difference might arise <br>
with "mixing bytes from different pointers". Say we are storing pointer "ptr1" <br>
directly followed by "ptr2" on a 64bit machine, and now we are doing an <br>
(unalinged) 8-byte load covering the last 4 bytes of ptr1 and the first 4 bytes <br>
of ptr2. This is certainly a valid value for b64. Is it also a valid value at <br>
pointer type, and if yes, which provenance does it have?<br></blockquote><div><br></div><div>This kind of example is why I was implicitly assuming that we must have a "provenance union" operation anyway, whether we like it or not. I suppose the alternative is to say that pointers formed in this way, whether directly or indirectly, are poison, but I have my doubts whether this is feasible. What happens with pointer arithmetic where you start out with two pointers of different provenance, convert to integer in the source language, subtract them, use the result further in some way, and for some reason all steps are performed with "byte" types in LLVM IR?</div><div><br></div><div>Cheers,</div><div>Nicolai<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Kind regards,<br>
Ralf<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.</div></div>