[llvm-dev] Inline assembly and poison values

[Johannes Doerfert via llvm-dev]

On 12/12/21 14:51, Leo Gaspard via llvm-dev wrote:
> Johannes Doerfert <johannesdoerfert at gmail.com> writes:
>>> 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?
>> I think the second solution is what you want. We also do not
>> define the semantics of inline ASM, so how could we say what
>> it means if poison goes in. Inline ASM, as it stands, should
>> always be allowed to produce poison, write poison into output
>> registers, etc. If we want ways to encode it does not, that's
>> a different story. That said, I'm not sure why explicit freeze
>> would be bad for the output, and for the input we probably
>> don't care as we do not "analyze" the asm anyway. No?
> It totally makes sense to me! Out of curiosity, what is the process for
> adding a clause like the below in the reference? (eg. waiting some delay
> then submitting a formal change, getting it reviewed and landing it?)

"like the below"? I'm confused. Adding an IR extensions requires
a RFC on the mailing list, look for recent ones to see what format
they can have. Motivation, semantics, etc. Then (or together) a
patch for the LangRef and the IR reader/writer etc. Then preferably
some users in the code base so it's not just pretty but useful ;)

Does that answer the question?

~ Johannes


>
>>> 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 and the exact contents of the assembly
>>> block. In particular, the backend is allowed to peer into the
>>> assembly block and optimize depending on that.
> PS: Sorry for the duplicate mail on your personal email, I forgot to use
> the correct sender address
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev