This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RTL cprop vs. fixed hard regs
- From: Alan Modra <amodra at gmail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 17 Jan 2015 11:07:12 +1030
- Subject: Re: RTL cprop vs. fixed hard regs
- Authentication-results: sourceware.org; auth=none
- References: <20150116094227 dot GV23768 at bubble dot grove dot modra dot org> <20150116170324 dot GB12714 at gate dot crashing dot org>
On Fri, Jan 16, 2015 at 11:03:24AM -0600, Segher Boessenkool wrote:
> On Fri, Jan 16, 2015 at 08:12:27PM +1030, Alan Modra wrote:
> > OK, so we need to fix this in the rs6000 backend, but it occurs to me
> > that cprop also has a bug here. It shouldn't be touching fixed hard
> > registers.
>
> Why not? It cannot allocate a fixed reg to a pseudo, but other than
> that there is nothing special about fixed regs; the transform is
> perfectly valid as far as I see.
I didn't say that copying to a pseudo and using that was invalid..
The bug I see is a mis-optimisation. Also, the asm operands case that
do_local_cprop already rules out changing is very similar to fixed
regs. Would you argue that changing asm operands is also valid? :)
> It isn't a desirable transform in this case, but that is not true for
> fixed regs in general (just because the stack pointer is live everywhere).
What's the point in extending the lifetime of some pseudo when you
know the original fixed register is available everywhere? Do you have
some concrete example in mind where this "optimisation" is beneficial?
Some ports even include pc in fixed_regs. So there are obvious
examples where regs in fixed_regs change behind the compiler's back.
Naive users might even expect to see the "current" value of those
regs. (Again, I'm not saying that it is invalid if gcc substituted an
older value.)
--
Alan Modra
Australia Development Lab, IBM