This is the mail archive of the
mailing list for the GCC project.
Re: inline asm and multi-alternative constraints
- From: Jeff Law <law at redhat dot com>
- To: David Wohlferd <dw at LimeGreenSocks dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: pinskia at gcc dot gnu dot org, rearnsha at gcc dot gnu dot org
- Date: Fri, 6 Nov 2015 15:29:43 -0700
- Subject: Re: inline asm and multi-alternative constraints
- Authentication-results: sourceware.org; auth=none
- References: <562DA0E2 dot 1040405 at LimeGreenSocks dot com> <562FE71E dot 7010309 at redhat dot com> <563285D8 dot 6020001 at redhat dot com> <563430F8 dot 7020406 at LimeGreenSocks dot com> <5637EC6F dot 7020505 at redhat dot com> <5637F50A dot 1090002 at codesourcery dot com> <56385495 dot 1050507 at LimeGreenSocks dot com>
On 11/02/2015 11:30 PM, David Wohlferd wrote:
It's never easy to predict whether or not something like this will be
contentious. Worst case is you post, it's contentious, we iterate a bit
and reach some kind of resolution (ok, worst case is no resolution is
reached, but that doesn't happen to often).
I think the fundamental problem here is we ought not be exposing those
modifiers to the user. They're inherently tied to the details of the
register allocation and reloading passes.
This is what I'm thinking as well.
The only reason I didn't delete them before is that removing support for
an existing feature can be contentious. But I see no practical way to
doc this for compiler-users. And even as an inline-asm aficionado, I
can't think of any use for them anyway. Since there seems to be
consensus, they're gone.
In this case I simply don't see a way to sensibly document those
modifiers without bringing in the implementation details of register
class preferencing, reload, IRA & LRA. And once those details are
brought into the picture, everyone loses.
I'm sure there's someone out there using '?' and '!' in a
multi-alternative asm constraint. They may even read the docs and
complain and we can try to educate them why those modifiers are no
It's a reasonable simple example which shows how one might use
multi-alternative constraints in an asm. It doesn't have to be
real-world, it has to be understandable and extendable to something a
user might want to do. I think this example fits that reasonably well.
Why would a user even need multi-alternative constraints in inline
asm? An insn template might be instantiated in many different
contexts and need to deal with different flavors of operands, but
inline asm code is generally unique and the programmer writing it
knows very well what the operands are supposed to be (this one is a
register, that one is an address, etc).
I wouldn't go that far. There are libraries that use inline asm
(sometimes in headers), and a library cannot know how it may be used.
The only practical approach for them is to list all options so gcc can
do its best.
Choosing the most efficient form of a logical-or instruction is hardly
a good motivating example, either -- nobody writes inline asm to do that.
However, it does make a good example for machine definitions, which also
@includes this file. And while perhaps not an optimal sample for inline
asm, it is a reasonable one, since other platforms (including x86) have
a similar instruction which has similar limitations.
I'm under the impression that the primary uses of inline asm are
either to access machine instructions not exposed by builtins, or to
provide a block of highly tuned code replacing all/most of a C
I have attached a new patch. It removes the flags and the paragraph
that tries to describe how the alternative is chosen from the non-md
docs. Now it just says the compiler will choose the most efficient
Other than the line about "All operands for a single instruction must
have the same number of alternatives", the 'internals' docs (which also
includes this file) should be unaffected.
This looks fine. I'll install it momentarily.