[llvm-dev] [RFC] Introducing a byte type to LLVM

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 22 22:27:27 PDT 2021

On Tue, Jun 22, 2021 at 11:59 AM Ralf Jung via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I don't think it makes sense for LLVM to adopt an explicit "exposed" flag
> in its
> semantics. Reasoning based on non-determinism works fine, and has the
> advantage
> of keeping ptr-to-int casts a pure, side-effect-free operation. This is
> the
> model we explored in <https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf>,
> and
> we were able to show quite a few of LLVM's standard optimizations correct
> formally. Some changes are still needed as you noted, but those changes
> will be
> required anyway even if LLVM were to adopt PNVI-ae:
> - No removal of ptr-int-ptr roundtrips.
> (https://bugs.llvm.org/show_bug.cgi?id=34548)
> - No GVN replacement of pointer-typed values.
> (https://bugs.llvm.org/show_bug.cgi?id=35229)

I've read this paper now, and it makes good sense to me as something to
adopt in LLVM.

I do have one question about a point that doesn't seem sufficiently
justified, though. In the semantics of the paper,
store-pointer-then-load-as-integer results in poison. This seems to be the
root cause for being forced to introduce a "byte" type for correctness, but
it is only really justified by an optimization that eliminates a store that
writes back a previously loaded value. That optimization doesn't seem all
that important (but feel free to point out why it is...), while introducing
a "byte" type is a massive change. On the face of it, that doesn't seem
like a good trade-off to me.

Has the alternative of allowing type punning through memory at the cost of
removing that optimization been studied sufficiently elsewhere?


Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210623/fbd41df9/attachment.html>

More information about the llvm-dev mailing list