All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Richard Henderson <rth@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vladimir Makarov <vmakarov@redhat.com>,
	Jakub Jelinek <jakub@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [RFC] Design for flag bit outputs from asms
Date: Tue, 5 May 2015 08:50:05 -0500	[thread overview]
Message-ID: <20150505135005.GA4850@gate.crashing.org> (raw)
In-Reply-To: <5547C992.9000703@redhat.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 :-)


Segher

  parent reply	other threads:[~2015-05-05 16:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 15:16 [PATCH] x86: Optimize variable_test_bit() Peter Zijlstra
2015-05-01 16:03 ` Linus Torvalds
2015-05-01 16:16   ` Peter Zijlstra
2015-05-01 16:29     ` Peter Zijlstra
2015-05-01 16:18   ` Peter Zijlstra
2015-05-01 16:33   ` Jakub Jelinek
2015-05-01 16:45     ` Linus Torvalds
2015-05-01 16:46     ` Peter Zijlstra
2015-05-01 17:17       ` Ingo Molnar
2015-05-01 19:02     ` Vladimir Makarov
2015-05-01 20:49       ` Linus Torvalds
2015-05-01 22:22         ` Vladimir Makarov
2015-05-02 12:39         ` Peter Zijlstra
2015-05-04 15:37           ` Richard Henderson
2015-05-04 19:33           ` [RFC] Design for flag bit outputs from asms Richard Henderson
2015-05-04 20:14             ` H. Peter Anvin
2015-05-04 20:27               ` H. Peter Anvin
2015-05-04 20:33               ` Richard Henderson
2015-05-04 20:45                 ` Linus Torvalds
2015-05-04 20:57                   ` Richard Henderson
2015-05-04 21:23                     ` H. Peter Anvin
2015-05-04 20:35               ` Linus Torvalds
2015-05-04 20:42                 ` H. Peter Anvin
2015-05-05  9:01             ` Gabriel Paubert
2015-05-05 13:50             ` Segher Boessenkool [this message]
2015-05-05 15:37               ` Linus Torvalds
2015-05-05 16:10                 ` Segher Boessenkool
2015-05-02 12:43       ` [PATCH] x86: Optimize variable_test_bit() Peter Zijlstra
2015-05-04 18:07         ` Vladimir Makarov
2015-05-04 20:14           ` H. Peter Anvin
2015-05-04 13:42 ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150505135005.GA4850@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bp@alien8.de \
    --cc=gcc@gcc.gnu.org \
    --cc=hpa@zytor.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rth@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vmakarov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.