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

[Dmitry Vyukov via cfe-dev]

On Thu, Mar 21, 2019 at 7:15 PM James Y Knight <jyknight at google.com> wrote:
>
> 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.

You mean we assume C code is buggy and asm code is not buggy because
compiler fails to disprove that there is a bug?
Doing this optimization without -ftrivial-auto-var-init looks
reasonable, compilers do optimizations assuming absence of bugs
throughout. But -ftrivial-auto-var-init is specifically about assuming
these bugs are everywhere.

> 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