[PATCH] D114895: [SelectionDagBuilder] improve CallBrInst BlockAddress constraint handling

[Nick Desaulniers via Phabricator via llvm-commits]

nickdesaulniers added a comment.

In D114895#3178134 <https://reviews.llvm.org/D114895#3178134>, @void wrote:

> In D114895#3178108 <https://reviews.llvm.org/D114895#3178108>, @nickdesaulniers wrote:
>
>> In D114895#3177794 <https://reviews.llvm.org/D114895#3177794>, @efriedma wrote:
>>
>>> In D114895#3170282 <https://reviews.llvm.org/D114895#3170282>, @nickdesaulniers wrote:
>>>
>>>> Unless you can tie a block address. Hopefully `"+r"(&&goto_label)` isn't a valid output constraint...
>>>>
>>>>   void x(void) {
>>>>       asm goto ("":"+r"(&&foo):::foo);
>>>>       //                ^ error: lvalue required in 'asm' statement
>>>>       foo:;
>>>>   }
>>>
>>> I think you meant to write something like this:
>>>
>>>   void *x(void) {
>>>       void *p = &&foo;
>>>       asm goto ("":"+r"(p):::foo);
>>>       foo:;
>>>       return p;
>>>   }
>>
>> Damn! Then yeah, this approach (Diff 392533) is still broken.
>
> I must be missing something. Isn't that just simply reassigning the variable `p` and not using the label `foo` for output?

The corresponding IR (trimmed for brevity) for @efriedma 's example above is:

  %1 = callbr i8* asm "", "=r,X,0,~{dirflag},~{fpsr},~{flags}"(i8* blockaddress(@x, %3), i8* blockaddress(@x, %3)) #1
          to label %2 [label %3]

So because `p` is an `InOutArg` (see also `CodeGenFunction::EmitAsmStmt` in clang/lib/CodeGen/CGStmt.cpp), technically the first `blockaddress` in the parameter list of the `callbr` is the indirect destination, while the second is the hidden tied-input.

`InOutArgBias` in my Diff 392533 would then be 0, since it's written to assume that the latest `blockaddress` in the argument list is the final possible indirect destination. @efriedma 's example shows that assumption is incorrect, and thus that Diff 392533 is still subtly broken.

@efriedma 's example shows that the address of the `foo` label is output. That doesn't make too much sense as an output in C, but it does mean that the address of `foo` could be written to by the inline asm string.  I hope that's not useful to anyone...but I get a sense I might eat those words one day...plz no.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114895/new/

https://reviews.llvm.org/D114895