This is the mail archive of the
mailing list for the GCC project.
Re: inline asm and multi-alternative constraints
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, Jeff Law <law at redhat dot com>
- Cc: 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>, pinskia at gcc dot gnu dot org, rearnsha at gcc dot gnu dot org
- Date: Fri, 6 Nov 2015 23:50:40 -0800
- 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> <563D29D7 dot 9000707 at redhat dot com> <20151107004639 dot GA27264 at gate dot crashing dot org>
On 11/6/2015 4:46 PM, Segher Boessenkool wrote:
On Fri, Nov 06, 2015 at 03:29:43PM -0700, Jeff Law 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).
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.
This very point is what made it clear to me that these flags should be
removed. If there is no practical way to describe to the target
audience how they work or when to use them, they don't belong here.
I'll take partial credit for asking the questions that highlighted the
problem, but Jeff taking the time to respond to them is what got us to
the right answer here (thanks Jeff!).
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
Another reason why we shouldn't document such things is that it makes
it harder to change (anything about) those things later, although they
really are implementation details.
True. In this case, they were already documented and the change was to
remove them, something I hesitate to do. But I think what Jeff checked
in (thanks Jeff!) gives us the right answer for this page.
The same goes for some constraints and almost all output modifiers.
Are you suggesting more doc changes? Looking thru the pages you reference:
- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm. But both "#*" seem sketchy.
- Under 'simple constraints', "mringX" all (more or less) make sense to
me. But "oV<>sp" are not things I can envision using.
- The 'machine constraints' for i386 (the only machine I know) all seem
reasonable. However for platforms that support autoincrement
(powerpc?), apparently using "m" needs more docs (per
Are these the things to which you are referring? I've always assumed
the parts that seem obscure here were due to my i386-centric view of the
world. Are some of them actually md-only?
There are other minor changes I'd make on some of these pages. But
mostly they are not worth it unless I'm doing something else there too.
So if there's something here you think needs changing, let me know and
I'll take a crack at it.
Other than that, I'll keep working my way thru the doc issues in the
inline-asm bugs. I've done what I can for 10396.