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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5547D30B.2020507@zytor.com>
Date:	Mon, 04 May 2015 13:14:03 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Richard Henderson <rth@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Vladimir Makarov <vmakarov@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	"gcc@....gnu.org" <gcc@....gnu.org>
Subject: Re: [RFC] Design for flag bit outputs from asms

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