This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: IRA patch: move clobbers downwards
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Vladimir N. Makarov" <vmakarov at redhat dot com>
- Date: Wed, 14 Jul 2010 23:44:21 +0200
- Subject: Re: IRA patch: move clobbers downwards
- References: <4C3C34B4.3070309@codesourcery.com> <4C3E0EB7.5030906@redhat.com>
On 07/14/2010 09:23 PM, Jeff Law wrote:
> When I first looked at this, I kept hearing a little voice saying I'd
> seen this discussion before. So I did some searching today :-)
>
> The first thread starts here:
>
> http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01651.html
Lovely :-)
>> The real problem here is that IRA does a backwards scan; just as in
>> peep2, it would probably be better to use a forwards scan using REG_DEAD
>> notes. However, I'm told it's expensive to create those.
>>
> Just so I'm clear, we're doing a backwards life analysis. We see one or
> more assignments to the components of a double-word pseudo which makes
> the pseudo live. The pseudo is assumed to still be live until we find
> its clobber thus making the pseudo live between the clobber and the
> component assignments, even though it holds no useful value. Right?
That's what happens. SETs of DF_REF_PARTIAL things are ignored for the
purpose of tracking liveness.
With a forward scan we'd ignore the clobbers and mark the reg live on
the first partial set, getting the right answer.
> I guess we could compensate for this with some special clobber handling
> when computing lifetimes, but just moving the clobbers after sched might
> be the best solution.
Since we seem to have decided to use my IRA subword patch, the issue is
a bit moot. We can still run into trouble for
(clobber (reg:SI x))
(set (zero_extract (reg x) (low half)) (something))
(set (zero_extract (reg x) (high half)) (something else))
which IIRC happens for CHImode and maybe some other cases. It's
probably no longer that important.
Bernd