[Bug c/105046] New: [enhancement] Allow inline-assembly clobbers to overlap inputs
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 c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046 Elliott M changed: What|Removed |Added Component|middle-end |c --- Comment #4 from Elliott M --- 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/105048] New: [enhancement] Allow specific register constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105048 Bug ID: 105048 Summary: [enhancement] Allow specific register constraints 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: --- Using local register variables to constrain assembly-language inputs and outputs to particular registers is really ugly. Better to have explicit syntax for this. I would suggesting using "R" for this. Using "R" conflicts with x86, but x86 effectively already has this since "a", "b", "c", "d", "S", "D" covers most of the registers used for calling conventions. I though also note Clang doesn't appear to have implemented "R" which suggests this has rarely, if ever, been used. (another letter could be used on x86, or it might be possible to repurpose) This is particularly valuable for interfacing with systems using foreign calling conventions. The example is how one might interface with a hypervisor on ARM64. This seems valuable as the register specification is a feature of the inline-assembly-language, not a feature of the variable. This could result in superior output, by avoiding copies. In particular `hypercall_inline()` might well end up with 5 extra `mov` instructions (plus a call and return) which are never optimized out, whereas `hypercall_macro()` is rather likely to produce a single instruction.
[Bug c/105048] [enhancement] Allow specific register constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105048 --- Comment #1 from Elliott M --- Created attachment 52684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52684&action=edit Sample of with and without this feature Hmm, Bugzilla attachment during initial submission failed.
[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046 Elliott M changed: What|Removed |Added Component|middle-end |c --- Comment #6 from Elliott M --- 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/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #10 from Elliott M --- Eyes must have glazed over when trying to find other reports. 105048 is indeed a duplicate. Another option might be "R" for architectures which haven't already grabbed "R" for something else. I notice Clang though doesn't appear to have "R" implemented which seems to suggest actual uses of the current definition of "R" are rare. There are multiple calls for this feature, any chance of an implementation?
[Bug c/105046] [enhancement] Allow inline-assembly clobbers to overlap inputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046 --- Comment #7 from Elliott M --- 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.
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #11 from Elliott M --- (In reply to Andreas Schwab from comment #1) > x86 doesn't support this either. It just happens to have a few register > classes that consist of a single register, but only because of ISA > constraints. That is a *gross* mischaracterization. Constraint list for x86 includes: 'a', 'b', 'c', 'd', 'S', 'D'. Indeed, that doesn't include bp or sp, but does include *all* the registers which get used for interesting purposes (register-passing calling conventions). Perhaps people writing GCC haven't felt pressure to implement this since they're primarily dealing with x86 and x86 effectively already has this? I'm tempted to propose this to people involved with Clang, then come back here and suggest GCC should copy the feature...
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #13 from Elliott M --- (In reply to Andrew Pinski from comment #12) > Actually this is NOT a gross mischaracterization of GCC's x86 inline-asm and Making the 6 registers most likely to be needed on x86 available as machine-specific constraints makes the spirit of this request available for x86. It doesn't /quite/ fully implement the request, but does cover 95% of use cases, for x86. Whereas for modern architectures it is unavailable. > not understanding that is misrepresenting the history of GCC's inline-asm > and how it just exposes internal details of GCC to the user. GCC's x86 > constraints are exactly this way because of instructions requirements (ISA > constraints) and all of these constraints are used internally too. The documented limitations of GCC's extended inline assembly language were most readily explained by it exposing GCC's internals. As such I had already guessed this was the case. Unfortunately these limitations makes it extremely painful to use for actual benefit. (I see why most cases use full assembly language .S files, instead of inline assembly language)
