On 11/02/2015 11:30 PM, David Wohlferd wrote:
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.
I agree.
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.
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).
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
longer documented.
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.
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.
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
function body.
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
alternative.
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.
jeff
