public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Earnshaw <rearnsha@arm.com>
Cc: Christophe Lyon <christophe.lyon@linaro.org>,
	Jeff Law <law@redhat.com>,
	       "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	       "rsandifo@linux.vnet.ibm.com"
	<rsandifo@linux.vnet.ibm.com>
Subject: Re: RFA: cache enabled attribute by insn code
Date: Tue, 27 May 2014 15:50:00 -0000	[thread overview]
Message-ID: <20140527155010.GP10386@tucnak.redhat.com> (raw)
In-Reply-To: <5384B1DD.5080601@arm.com>

On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
> <quote>
> The @code{enabled} insn attribute may be used to disable certain insn
> alternatives for machine-specific reasons.
> <quote>
> 
> The rest of the text just says what happens when this is done and then
> gives an example usage.  It doesn't any time, either explicitly or
> implicitly, say that this must be a static choice determined once-off at
> run time.

It says:
"This definition should be based on other insn attributes and/or target flags."
where from what I understand Andreas originally meant was that the other
insn attributes would be again based on target flags or other such insn
attributes.  Yeah, it explicitly rules out just basing the enabled attribute on
the operands, arm uses just another attribute based on the operands there,
but it still goes against the intent of the attribute, and is definitely a
nightmare for the register allocator.
Decisions based on the operands should be through constraints.

From what I can see, arm uses it just on a single insn, so I'd say it
shouldn't be a big deal to rewrite it.

	Jakub

  reply	other threads:[~2014-05-27 15:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20  8:16 Richard Sandiford
2014-05-20  8:17 ` Richard Sandiford
2014-05-20 14:42   ` Mike Stump
2014-05-20 17:50 ` Jeff Law
2014-05-20 21:37   ` Richard Sandiford
2014-05-23 18:19     ` Jeff Law
2014-05-27 13:12       ` Christophe Lyon
2014-05-27 13:37         ` Ramana Radhakrishnan
2014-05-27 14:59           ` Christophe Lyon
2014-05-27 14:08         ` Richard Sandiford
2014-05-27 14:18           ` Richard Sandiford
2014-05-27 15:07             ` Richard Sandiford
2014-05-27 16:36               ` Christophe Lyon
2014-05-28 14:01               ` Yufeng Zhang
2014-05-29  9:43               ` Richard Earnshaw
2014-05-29 10:45                 ` Richard Sandiford
2014-05-27 15:15           ` Richard Earnshaw
2014-05-27 15:27             ` Jakub Jelinek
2014-05-27 15:40               ` Richard Earnshaw
2014-05-27 15:50                 ` Jakub Jelinek [this message]
2014-05-27 16:01                   ` Richard Earnshaw
2014-05-27 16:09                 ` Richard Sandiford
2014-05-27 16:21                   ` Richard Earnshaw
2014-05-27 16:31                     ` Richard Sandiford
2014-05-28 15:11                       ` Richard Earnshaw

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=20140527155010.GP10386@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=rearnsha@arm.com \
    --cc=rsandifo@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).