public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <richard.guenther@gmail.com>
To: Bernd Schmidt <bernds@codesourcery.com>
Cc: Steven Bosscher <stevenb.gcc@gmail.com>,
		Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>,
	Andrew Stubbs <ams@codesourcery.com>,
		Richard Earnshaw <rearnsha@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
		"patches@linaro.org" <patches@linaro.org>
Subject: Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)
Date: Wed, 08 Feb 2012 12:32:00 -0000	[thread overview]
Message-ID: <CAFiYyc2nX4aKMmguL2PUh=ZiROtRc5aKjpFYJAQfsRctp8GYkA@mail.gmail.com> (raw)
In-Reply-To: <4F32645F.4050606@codesourcery.com>

On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
>> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>> <ramana.radhakrishnan@linaro.org> wrote:
>>> Hi Andrew
>>>
>>> I find it interesting that cond_exec's in this form survive all the
>>> way till reload and "work".  AFAIK we could never have cond_exec's
>>> before reload .
>>
>> There is nothing wrong per-se with cond_execs before reload, as long
>> as you don't have to reload a predicate pseudo-reg.
>
> I thought the problem was that we'd have to emit conditional reload
> insns and inheritance wouldn't work.

It probably depends on how DF sees conditional uses / defs.  If they
look like regular uses / defs then I suppose un-conditional spills/reloads
are fine - otherwise of course you'd corrupt one of the two register set
states.  But that also means it's probably safe if the sequence of conditional
insns is of length 1.

Not sure we want to open that possible can of worms though ;)

Richard.

>
> Bernd

  reply	other threads:[~2012-02-08 12:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 16:07 Andrew Stubbs
2012-01-30 15:26 ` Richard Earnshaw
2012-01-31 14:29   ` Andrew Stubbs
2012-02-07 22:20     ` Ramana Radhakrishnan
2012-02-07 22:34       ` Steven Bosscher
2012-02-08 12:13         ` Bernd Schmidt
2012-02-08 12:32           ` Richard Guenther [this message]
2012-02-08 13:01             ` Bernd Schmidt
2012-02-08 13:33               ` Richard Guenther
2012-02-08 11:34       ` Andrew Stubbs
2012-02-08 16:43         ` Andrew Stubbs
2012-02-11  2:41           ` Richard Henderson
2012-02-16 16:08             ` Andrew Stubbs
2012-02-17 17:42               ` Andrew Stubbs
2012-05-16 10:26                 ` Ramana Radhakrishnan
2012-05-16 16:09                   ` Andrew Stubbs
2012-05-16 16:44                     ` Ramana Radhakrishnan
2012-05-18  9:12                       ` Andrew Stubbs

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='CAFiYyc2nX4aKMmguL2PUh=ZiROtRc5aKjpFYJAQfsRctp8GYkA@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=ams@codesourcery.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=patches@linaro.org \
    --cc=ramana.radhakrishnan@linaro.org \
    --cc=rearnsha@arm.com \
    --cc=stevenb.gcc@gmail.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).