On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote: > On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool > <seg...@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
