This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Design for flag bit outputs from asms
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Peter Zijlstra <peterz at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Vladimir Makarov <vmakarov at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Ingo Molnar <mingo at kernel dot org>, "H. Peter Anvin" <hpa at zytor dot com>, Thomas Gleixner <tglx at linutronix dot de>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, Borislav Petkov <bp at alien8 dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 5 May 2015 08:50:05 -0500
- Subject: Re: [RFC] Design for flag bit outputs from asms
- Authentication-results: sourceware.org; auth=none
- References: <20150501151630 dot GH5029 at twins dot programming dot kicks-ass dot net> <CA+55aFwBP9QjpRK50pdVHmc086-+QPCthJRUs8Gq5qJBnXqnJQ at mail dot gmail dot com> <20150501163329 dot GU1751 at tucnak dot redhat dot com> <5543CDC0 dot 6010206 at redhat dot com> <CA+55aFxOd6mJcezgoLHN9Zgds-CsJqsx4Jgkp9OP1xUf11727Q at mail dot gmail dot com> <20150502123958 dot GK5029 at twins dot programming dot kicks-ass dot net> <5547C992 dot 9000703 at redhat dot com>
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
> (1) Each target defines a set of constraint strings,
> (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.
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.
> Note that the output constraints are adjusted to a single internal "=j_"
> which would match the flags register in any mode. We can collapse
> several output flags to a single set of the flags hard register.
Many targets would use an already existing contraint that describes the
flags. Targets that need a fixed register could just insert the hard
register here as far as I see? (I'm assuming this happens at expand time).
> (3) Note that ppc is both easier and more complicated.
> There we have 8 4-bit registers, although most of the integer
> non-comparisons only write to CR0. And the vector non-comparisons
> only write to CR1, though of course that's of less interest in the
> context of kernel code.
> For the purposes of cr0, the same scheme could certainly work, although
> the hook would not insert a hard register use, but rather a pseudo to
> be allocated to cr0 (constaint "x").
And "y" for "any CR field".
> That said, it's my understanding that "dot insns", setting cr0 are
> expensive in current processor generations.
They are not. (Cell BE is not "current" :-) )
PowerPC also has some other bits (the carry bit for example, CA) that
could be usefully exposed via this mechanism.
> Can anyone think of any drawbacks, pitfalls, or portability issues to less
> popular targets that I havn't considered?
I don't like co-opting the constraint names for this; other than that, it
looks quite good :-)