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

[Segher Boessenkool <segher@kernel.crashing.org>]

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@kernel.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