<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jul 5, 2018 at 11:28 AM Friedman, Eli via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/5/2018 7:01 AM, Ties Stuij via cfe-dev wrote:<br>
> Hi all,<br>
><br>
> I'm looking at an issue where when specifying a reserved register (fp, base pointer) on the clobber list of an asm() statement, we don't preserve the original value across the asm code. Practically the register in the clobber list is ignored in this case, so if we're overwriting it in our asm code, we have problems.<br>
><br>
> As the clobber list is a GCC extension, I looked at the GCC behaviour, and GCC is doing roughly the same thing. There is a GCC bug out on this (<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807</a>), and the opinions are somewhat divided on how to proceed.<br>
><br>
> There's a few ways in which we think we'd like to resolve this:<br>
> 1 - leave as is, and be in line with GCC<br>
> 2 - error when we see the SP and PC on the clobber list, otherwise store and load around the assembly code<br>
> 3 - error on any reserved register on the clobber list<br>
><br>
> Where option 1 doesn't sound like a very nice option to me as it's counter-intuitive, and seems quite shoot-in-the-foot-y.<br>
><br>
> Any opinions on this?<br></blockquote><div><br></div><div>Would it be good enough if we changed LLVM to eliminate the need for the third reserved register, the so-called "base pointer" that Eli mentioned? This is usually what trips people up on X86 (RBX vs. cpuid: <a href="https://llvm.org/pr16830">https://llvm.org/pr16830</a>). Most users know they aren't supposed to muck with SP or FP registers. You can imagine making the base pointer into a virtual register that could be spilled, reloaded, or rematerialized as needed.</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">
Regardless of how much of a footgun this is, we'll get a ton of <br>
complaints if we print an error in any case where gcc doesn't, so any <br>
new diagnostics would need to be a warning, at least at first.<br>
<br>
"otherwise store and load around the assembly code" makes sense for <br>
cases where the compiler is arbitrarily reserving registers, like <br>
fp/base ptr in a function that contains a VLA.  In particular, the <br>
"base" register isn't really specified anywhere, so we can't expect <br>
users to consistently avoid it.<br>
<br>
Printing a diagnostic for code that tries to clobber "sp" or "pc" makes <br>
sense; that can't do anything useful in any context.  Probably also <br>
makes sense to print a diagnostic for other fundamentally reserved <br>
registers, like the frame pointer with -fno-omit-frame-pointer, or x18 <br>
on AArch64 targets where it's reserved, rather than try to do something <br>
which might have surprising results.<br></blockquote><div><br></div><div>At some point when we were working on MS inline asm, we decided that inline asm clobbering SP should be treated as a dynamic alloca, i.e. a frame pointer should be used to address local variables.</div></div></div>