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.
>
> Therefore:
>
> (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.
>
> E.g.
>
> bool x, y, z;
> asm ("xyzzy" : "=jc"(x), "=jp"(y), "=jo"(z) : : );
Other than that, this is exactly what would be wonderful to see.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
