<div dir="ltr"><div dir="ltr">On Thu, Jun 27, 2019 at 1:44 PM Bill Wendling <<a href="mailto:isanbard@gmail.com">isanbard@gmail.com</a>> wrote:<br></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 dir="ltr">On Thu, Jun 27, 2019 at 1:29 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br></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">I think this is fine, except that it stops at the point where things actually start to get interesting and tricky.<div><br></div><div>How will you actually handle the flow of values from the callbr into the error blocks? A callbr can specify requirements on where its outputs live. So, what if two callbr, in different branches of code, specify _different_ constraints for the same output, and list the same block as a possible error successor? How can the resulting phi be codegened?</div><div><br></div></div></blockquote><div>This is where I fall back on the statement about how "the programmer knows what they're doing". Perhaps I'm being too cavalier here? My concern, if you want to call it that, is that we don't be too restrictive on the new behavior. For example, the "asm goto" may set a register to an error value (made up on the spot; may not be a common use). But, if there's no real reason to have the value be valid on the abnormal path, then sure we can declare that it's not valid on the abnormal path.</div><div><br></div></div></div></blockquote><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><br></div><div>-bw</div><div> </div><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></div><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></div><div>It'd sure be a whole lot easier to not have the values valid on the secondary exit blocks. Can you present examples where preserving the values on the branches is be a requirement? (I feel like I've seen some before, but it'd be good to be reminded).<br></div><div><br></div><div>E.g., imagine code like this:</div><div><br></div><div><<</div><div>entry:</div><div>  br i1 %cmp, label %true, label %false</div><div>true:</div><div>  %0 = callbr { i32, i32 } asm sideeffect "poetry $0, $1", "={r8},={r9},X" (i8* blockaddress(@vogon, %error)) to label %asm.fallthrough [label %error]<br></div><div>false:<br></div><div>  %1 = callbr { i32, i32 } asm sideeffect "poetry2 $0, $1", "={r10},={r11},X" (i8* blockaddress(@vogon, %error)) to label %asm.fallthrough [label %error]</div><div><br></div><div>error:</div><div>  %vals = phi { i32, i32 } [ %0, %true ], [ %1, %false ]</div><div>>></div><div><br></div><div>Normally, if a common register cannot be found to use across relevant block transitions, it can simply fall back on storing values on the stack. But, that's not possible with callbr, since the location is fixed by the asm, and no code can be inserted after the values are written, before the branch (as both value writes and the branch are inside the asm blob). So what can be done, in that case?</div><div><br></div><div>One thing you might be able to do is to duplicate the error block so you have a different target for every callbr, but I'd consider that an invalid transform (because the address of the block is potentially being used as a value in the asm too).<br></div><div><br></div><div>Another thing you could perhaps do is reify the source-block-number as an actual value -- storing a "1" before the callbr in true, and storing a "2" before the callbr in "false". Then conditional-branch based on that...but that's real ugly...</div></div>
</blockquote></div></div>
</blockquote></div></div>