[cfe-dev] [RFC] ASM Goto With Output Constraints

[Reid Kleckner via cfe-dev]

On Fri, Jun 28, 2019 at 12:00 PM Bill Wendling via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I think I should explain my "programmer knows what they're doing"
> statement a bit better. I'm specifically referring to inline asm here. The
> more general "callbr" case may still need to be considered (see Reid's
> reply).
>
> When a programmer uses inline asm, they're implicitly telling the compiler
> that they *do* know what they're doing  (I know this is common knowledge,
> but I wanted to reiterate it.). In particular, either they need to
> reference an instruction not readily available from the compiler (e.g.
> "cpuid") or the compiler isn't able to give them the needed performance in
> a critical section. I'm extending this sentiment to callbr with output
> constraints. Let's take your example below and write it as "normal" asm
> statements one on each branch of an if-then-else (please ignore any syntax
> errors):
>
> if:
>   br i1 %cmp, label %true, label %false
>
> true:
>   %0 = call { i32, i32 } asm sideeffect "poetry $0, $1", "={r8},={r9}" ()
>   br label %end
>
> false:
>   %1 = call { i32, i32 } asm sideeffect "poetry2 $0, $1", "={r10},={r11}"
> ()
>   br label %end
>
> end:
>   %vals = phi { i32, i32 } [ %0, %true ], [ %1, %false ]
>
> How is this handled in codegen? Is it an error or does the back-end handle
> it? Whatever's done today for "normal" inline asm is what I *think* should
> be the behavior for the inline asm callbr variant. If this doesn't seem
> sensible (and I realize that I may be thinking of an "in a perfect world"
> scenario), then we'll need to come up with a more sensible solution which
> may be to disallow the values on the error block until we can think of a
> better way to handle them.
>

I guess distinguishing between callbr and asm goto is reasonable. We can
tolerate optionally initialized outputs for inline asm. It's just the same
as having an output constraint register that you forget to write in the asm
blob. However, it would be good if callbr had some way to represent whether
the returned value is alive along any particular outgoing edge.

I mentioned that we could look to landingpad for inspiration here. I
mention it because it is, essentially, the alternate exceptional return
value of a possibly throwing call. The values it produces are carried in
the usual X86 return registers, RAX:RDX, so they really are kind of an
alternate return value. However, with asm goto, it's not possible to have
different output constraints along different edges, so after thinking about
it some more, I think this is overkill. It's just one way we could
implement that live value indication, and I think it's probably not as good
as changing callbr itself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190628/c17b6f62/attachment.html>