This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inline asm and multi-alternative constraints

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]