[Bug c/105046] New: [enhancement] Allow inline-assembly clobbers to overlap inputs

[Bug c/105046] New: [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

            Bug ID: 105046
           Summary: [enhancement] Allow inline-assembly clobbers to
                    overlap inputs
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: inline-asm
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ehem+gccbugs at m5p dot com
  Target Milestone: ---

From:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers

"Clobber descriptions may not in any way overlap with an input or output
operand. For example, you may not have an operand describing a register class
with one member when listing that register in the clobber list. Variables
declared to live in specific registers (see Explicit Register Variables) and
used as asm input or output operands must have no part mentioned in the clobber
description. In particular, there is no way to specify that input operands get
modified without also specifying them as output operands."

Inline assembly language SHOULD be able to clobber inputs.  Forcing clobbered
inputs to be declared as outputs (which also forces them to be lvalues) is a
recipe for introducing bugs into programs.

The documentation leaves me with the impression this restriction was introduced
with the initial implementation of extended inline assembly language (likely
pre-2000).  I suspect improvements in the back-end likely mean this can be
readily removed.

I'm unsure about allowing outputs to overlap clobbers.  If the clobber list is
treated as a list of registers/memory which are modified, then it would make
sense to allow outputs to be clobbered.  Issue is whether this is allowing
programmers to be sloppy and cause more bugs, versus making the job easier.

Alternatively a '-' prefix could be added for marking inputs which are
clobbered in the assembly language.  This could be a nicer expression, but
changes the language.

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
          Component|c                           |middle-end

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Basically extended inline-asm in gcc exposes the internals representation to
the users. I can expand on this on why things like this request is bad for the
representation and all.

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And you provide an example of why you want this improvement?

[Bug middle-end/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, it certainly doesn't force them to be lvalues.
You can do something like:
  int dummy;
  __asm ("whatever" : "=c" (dummy) : "0" (256) : "edi");
to say you want rvalue 256 in 32-bit %ecx register and say that the %ecx
register is clobbered in the inline asm and %edi too.

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

Elliott M <ehem+gccbugs at m5p dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c

--- Comment #4 from Elliott M <ehem+gccbugs at m5p dot com> ---
I had guessed this was exposing internals, I had hopes those were the internals
from a score of years ago and could readily be resolved now.

This is valuable for interfacing with things which have calling conventions
distinct enough not to work with pure-C, but similar enough to only need 1-2
assembly instructions.  Notably avoiding lvalues is valuable for things which
could otherwise fit into macros.

Jakub Jelinek, your example fails, `dummy` is an lvalue.  Notably if this is
part of a `#define SOME_MACRO(foo)`, then `SOME_MACRO(dummy)` won't work.

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, but it doesn't force the input to be an lvalue.
You can add variables even in macros in statement expressions,
#define FOO(whatever) \
  ({ int dummy; __asm ("" : "=c" (dummy) : ...); retval; })

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

Elliott M <ehem+gccbugs at m5p dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c

--- Comment #6 from Elliott M <ehem+gccbugs at m5p dot com> ---
That is true, but you're still forcing the creation of an extra variable which
makes the macro less safe.  Notably `FOO(dummy)` will fail, whereas if inputs
could be marked clobbered the macro would only need a variable for return (for
which the macro name itself can be used, since that is guaranteed not to cause
problems).

[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs

[ehem+gccbugs at m5p dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046

--- Comment #7 from Elliott M <ehem+gccbugs at m5p dot com> ---
Guess I have to go for the visible use:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/xen/hypercall.h

Substantial amounts of the _hypercall#() macro definitions could be removed if
90181 and 105046 were done.  The overhead produced by having no way of choosing
named registers in the asm() construct and not allowing clobbers to overlap
inputs is pretty awful.  This in turn makes this difficult to read.

Additionally, attempting to warn about unused, but set variables becomes
difficult.  Several types of warnings are difficult or impossible since the
source has to lie about what is output versus input.