[llvm-dev] [RFC] Introducing a byte type to LLVM
Ralf Jung via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 23 05:52:03 PDT 2021
> 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?
> The transformation is analogous to removing memcpy-like code with the same dst
> and src.
> Such code might not be written by humans frequently, but I believe C++'s
> template instantiation or optimizations like inlining can expose such a case.
To add to what Juneyoung said:
I don't think that experiment has been made. From what I can see, the
alternative you propose leads to an internally consistent model -- one "just"
has to account for the fact that a "load i64" might do some transformation on
the data to actually obtain an integer result (namely, it might to ptrtoint).
However, I am a bit worried about what happens when we eventually add proper
support for 'restrict'/'noalias': the only models I know for that one actually
make 'ptrtoint' have side-effects on the memory state (similar to setting the
'exposed' flag in the C provenance TS). I can't (currently) demonstrate that
this is *required*, but I also don't know an alternative. So if this remains the
case, and if we say "load i64" performs a ptrtoint when needed, then that would
mean we could not do dead load elimination any more as that would remove the
There also is the somewhat conceptual concern that LLVM ought to have a type
that can loslessly hold all kinds of data that exist in LLVM. Currently, that is
not the case -- 'iN' cannot hold data with provenance.
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.
> Juneyoung Lee
> Software Foundation Lab, Seoul National University
More information about the llvm-dev