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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 5 May 2015 11:10:27 -0500
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Richard Henderson <rth@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Vladimir Makarov <vmakarov@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	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 Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote:
> On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool
> <segher@...nel.crashing.org> wrote:
> >
> > Since it is pre-processed, there is no real reason to overlap this with
> > the constraints namespace; we could have e.g. "=@[xy]" (and "@[xy]" for
> > inputs) mean the target needs to do some "xy" transform here.
> 
> In fact, standing out visually would be just a good thing, since it's
> pretty special even from a usage standpoint.
> 
> And are you actually planning to have flags as inputs? Because *that*
> sounds like a bad idea. It's pretty hard to turn a boolean into a flag
> value, while pretty much any archiecture has an operation like "setcc"
> to go the other way. And I don't think your machine descriptions have
> anything to "generate flags". You'd have to add fragile and complex
> machinery for something it is unlikely anybody ever wants.

It isn't hard (or expensive) to turn integers into flags, on many
targets.  It is nice to allow this at least in the generic part of
the code -- what targets do in their target hook is up to them.

It isn't fragile or complex.  Not useful on some archs, yes I certainly
believe that.  But the lovely thing about Richard's proposal is that it
actually is a very simple addition to what the compiler already does,
there are no hard new optimisations needed, it's just a bit of munging
to allow the user to write an asm with condition code in/outs.  Allowing
inputs is just another bool argument to the target hook.  I'd rather
have this more orthogonal than more specialised; it can be used for much
more than just condition codes.  It's not like the "more general" syntax
would be a burden, as far as I see.

Segher
--
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/