This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Design for flag bit outputs from asms
- From: Richard Henderson <rth at redhat dot com>
- To: "H. Peter Anvin" <hpa at zytor dot com>, Peter Zijlstra <peterz at infradead dot org>
- Cc: Linus Torvalds <torvalds at linux-foundation dot org>, Vladimir Makarov <vmakarov at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Ingo Molnar <mingo at kernel dot org>, Thomas Gleixner <tglx at linutronix dot de>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, Borislav Petkov <bp at alien8 dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 04 May 2015 13:33:39 -0700
- Subject: Re: [RFC] Design for flag bit outputs from asms
- Authentication-results: sourceware.org; auth=none
- References: <20150501151630 dot GH5029 at twins dot programming dot kicks-ass dot net> <CA+55aFwBP9QjpRK50pdVHmc086-+QPCthJRUs8Gq5qJBnXqnJQ at mail dot gmail dot com> <20150501163329 dot GU1751 at tucnak dot redhat dot com> <5543CDC0 dot 6010206 at redhat dot com> <CA+55aFxOd6mJcezgoLHN9Zgds-CsJqsx4Jgkp9OP1xUf11727Q at mail dot gmail dot com> <20150502123958 dot GK5029 at twins dot programming dot kicks-ass dot net> <5547C992 dot 9000703 at redhat dot com> <5547D30B dot 2020507 at zytor dot com>
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
> On 05/04/2015 12:33 PM, Richard Henderson wrote:
>> (0) The C level output variable should be an integral type, from bool on up.
>> The flags are a scarse resource, easily clobbered. We cannot allow user code
>> to keep data in the flags. While x86 does have lahf/sahf, they don't exactly
>> perform well. And other targets like arm don't even have that bad option.
>> Therefore, the language level semantics are that the output is a boolean store
>> into the variable with a condition specified by a magic constraint.
>> That said, just like the compiler should be able to optimize
>> void bar(int y)
>> int x = (y <= 0);
>> if (x) foo();
>> such that we only use a single compare against y, the expectation is that
>> within a similarly constrained context the compiler will not require two tests
>> for these boolean outputs.
>> (1) Each target defines a set of constraint strings,
>> E.g. for x86, wherein we're almost out of constraint letters,
>> ja aux carry flag
>> jc carry flag
>> jo overflow flag
>> jp parity flag
>> js sign flag
>> jz zero flag
> I would argue that for x86 what you actually want is to model the
> *conditions* that are available on the flags, not the flags themselves.
> There are 16 such conditions, 8 if we discard the inversions.
A fair point. Though honestly, I was hoping that this feature would mostly be
used for conditions that are "weird" -- that is, not normally describable by
arithmetic at all. Otherwise, why are you using inline asm for it?
> It is notable that the auxiliary carry flag has no Jcc/SETcc/CMOVcc
> instructions; it is only ever consumed by the DAA/DAS instructions which
> makes it pointless to try to model it in a compiler any more than, say, IF.
Oh yeah. Consider that dropped.