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

[Alexander Potapenko via cfe-dev]

On Thu, Mar 21, 2019 at 3:16 PM 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)
I'm also unsure it's at all correct to optimize this store away in the
case of a register output.
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html is vague about
whether a well-formed asm directive is supposed to initialize its
register outputs.
> > 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



-- 
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