<div dir="ltr"><div dir="ltr">On Fri, Jun 28, 2019 at 12:00 PM Bill Wendling via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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).</div><div><br></div><div>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):</div><div><br></div><div>if:</div><div>  br i1 %cmp, label %true, label %false</div><div><br></div><div>true:</div><div><div>  %0 = call { i32, i32 } asm sideeffect "poetry $0, $1", "={r8},={r9}" ()<br></div><div>  br label %end</div><div><br></div><div>false:<br></div><div>  %1 = call { i32, i32 } asm sideeffect "poetry2 $0, $1", "={r10},={r11}" ()</div><div>  br label %end</div><div><br></div><div>end:</div><div>  %vals = phi { i32, i32 } [ %0, %true ], [ %1, %false ]</div></div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>