[llvm-dev] Inline assembly and poison values

[Leo Gaspard via llvm-dev]

Johannes Doerfert <johannesdoerfert at gmail.com> writes:
> I very much hope inline asm can (in general) act like a freeze
> but does not have to. That is, if we ever look into the box we
> can determine if it does freeze or not, and consequently use the
> information for follow argumentation. However, unless we look
> into the box we cannot assume anything. Hence, asm does not
> propagate poison but also does not freeze the inputs. That means
> we shall not propagate poison trough (uninterpreted) asm but also
> not remove a subsequent freeze under the assumption the asm would
> have implicitly frozen the poison already.

Do I understand correctly if I say that this means that for defining
proper semantics of the assembly+IR group, this would require defining,
for each assembly backend, what “poison” translates to and from for it?

Or maybe documentation could just say “what exactly ‘poison’ means is
backend-specific, and the outputs of an assembly block handling poisoned
data can be, or not, poisoned depending on each backend” or something
similar, thus postponing the specification work for later?

Though it'd probably be better if it were possible to have a full spec
of what exactly poison means for each backend, I guess it can take a
while to check exactly how each poison can arise and what they should
translate to for each backend in order to enable as many optimizations
as possible