[cfe-dev] (not) initializing assembly outputs with -ftrivial-auto-var-init

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 21 11:14:51 PDT 2019


If an asm's constraints claim that the variable is an output, but then
don't actually write to it, that's a bug (at least if the value is actually
used afterwards). An output-only constraint on inline asm definitely does
_not_ mean "pass through the previous value unchanged, if the asm failed to
actually write to it". If you need that behavior, it's spelled "+m", not
"=m".

We do seem to fail to take advantage of this for memory outputs (again,
this is not just for ftrivial-auto-var-init -- we ought to eliminate manual
initialization just the same), which I'd definitely consider an
missing-optimization bug.


On Thu, Mar 21, 2019 at 10:16 AM Alexander Potapenko <glider at google.com>
wrote:

> On Thu, Mar 21, 2019 at 2:58 PM James Y Knight <jyknight at google.com>
> wrote:
> >
> > Please be more specific about the problem, because your simplified
> example doesn't actually show an issue. If I write this function:
> > int foo() {
> >   int retval;
> >   asm("# ..." : "=r"(retval));
> >   return retval;
> > }
> > it already does get treated as definitely writing retval, and optimizes
> away the initialization (whether you explicitly initialize retval, or use
> -ftrivial-auto-var-init).
> > Example: https://godbolt.org/z/YYBCXL
> This is probably because you're passing retval as a register output.
> If you change "=r" to "=m" (https://godbolt.org/z/ulxSgx), it won't be
> optimized away.
> (I admit I didn't know about the difference)
> > On Thu, Mar 21, 2019 at 8:35 AM Alexander Potapenko via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >>
> >> Hi JF et al.,
> >>
> >> In the Linux kernel we often encounter the following pattern:
> >>
> >> type op(...) {
> >>   type retval;
> >>   inline asm(... retval ...);
> >>   return retval;
> >> }
> >>
> >> , which is used to implement low-level platform-dependent memory
> operations.
> >>
> >> Some of these operations turn out to be very hot, so we probably don't
> >> want to initialize |retval| given that it's always initialized in the
> >> assembly.
> >>
> >> However it's practically impossible to tell that a variable is being
> >> written to by the inline assembly, or figure out the size of that
> >> write.
> >> Perhaps we could speculatively treat every scalar output of an inline
> >> assembly routine as an initialized value (which is true for the Linux
> >> kernel, but I'm not sure about other users of inline assembly, e.g.
> >> video codecs).
> >>
> >> WDYT?
> >>
> >>
> >> --
> >> Alexander Potapenko
> >> Software Engineer
> >>
> >> Google Germany GmbH
> >> Erika-Mann-Straße, 33
> >> 80636 München
> >>
> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> >> Registergericht und -nummer: Hamburg, HRB 86891
> >> Sitz der Gesellschaft: Hamburg
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190321/c6ae6f81/attachment.html>


More information about the cfe-dev mailing list