This is the mail archive of the
mailing list for the GCC project.
Re: inline asm and multi-alternative constraints
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, David Wohlferd <dw at LimeGreenSocks dot com>
- Cc: Jeff Law <law at redhat 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>, pinskia at gcc dot gnu dot org, rearnsha at gcc dot gnu dot org
- Date: Mon, 9 Nov 2015 10:03:14 +0000
- 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> <563DAD50 dot 1010701 at LimeGreenSocks dot com> <20151107092313 dot GA13062 at gate dot crashing dot org> <56406E01 dot 2060504 at foss dot arm dot com>
On 09/11/15 09:57, Richard Earnshaw wrote:
> On 07/11/15 09:23, Segher Boessenkool wrote:
>> On Fri, Nov 06, 2015 at 11:50:40PM -0800, David Wohlferd wrote:
>>>> 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.
>> Output modifiers, not constraint modifiers -- things like "%X0" in
>> the output template. Many are only useful in the machine description,
>> but some (like that 'X' for rs6000) are vital for asm as well.
> They're not just useful, they're essential on AArch64 and ARM. They're
> needed, for example, to get the 32/64-bit register sizing correct.
On the other hand, we have %S on ARM which cannot ever be used from
inline assembler: it matches the result of a match_operator rule with
complex internal structure that could never be generated from user code.
>>> - Under 'simple constraints', "mringX" all (more or less) make sense to
>>> me. But "oV<>sp" are not things I can envision using.
>> Some are more useful on some targets than on others, sure. But these
>> generic constraints are extremely unlikely to ever get a change; this
>> is not true for target constraints. If we want to delete (or change
>> semantics of) some target constraint, and that constraint is documented,
>> we have to fear the ire of the one or two users of that constraint.
>>> - 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
>> I think the manual (the "Simple Constraints" section) does describe it
>> all, but it could be clearer. The PowerPC 'm' description does a good
>> job of explaining things further (for that target).
>>> 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?
>> Almost everything can be used in asm as well, but many constraints etc.
>> are much less useful there.
>>> 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.
>> Thanks again :-)