Re: [RFC] Design for flag bit outputs from asms

[H. Peter Anvin]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/