This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Design for flag bit outputs from asms
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: Richard Henderson <rth at redhat 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:14:03 -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>
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.
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.
> (2) A new target hook post-processes the asm_insn, looking for the
> new constraint strings. The hook expands the condition prescribed
> by the string, adjusting the asm_insn as required.
> bool x, y, z;
> asm ("xyzzy" : "=jc"(x), "=jp"(y), "=jo"(z) : : );
Other than that, this is exactly what would be wonderful to see.