Jeff,
I take your point and will go back over my splitters as I know one
instance in which a splitter can create such an issue.
(I should checlk for a constant operand after simplifying an operand).
In the cases I looked at before this was not the situation.
Each splitter - or subreg lowering potentially creates (or rather
reveals) another cascade oppertunity - but current pass arrangement
provide no means to remove them (other than the trivial propagation in
local-alloc). That seems fundementally wrong.
So all targets that use split or have lowered subregs potentially have
excess register usage and instructions (how much - I dont know)
I dont follow how taking another psuedo inside split helps - that
still seems to be another cascade that local-alloc will not remove.
As a side issue, if the the current fwprop bug - which often only
propagates one operand, can be fixed, then I may be in better shape
(since the early pass may then remove any cascades remaining before it
hits splitters)
I am looking at my original problem again and trying to find some level
of earlier optimisation I can use (ie some form of earlier expansion or
combination). If I can remove some of the cascaded levels before split,
then things get much better!
But this is not easy.
thank you for your advise
-----Original Message-----
From: Jeff Law <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Sent: Mon, 25 Feb 2008 4:34 am
Subject: Re: Redundant logical operations left after early splitting
[EMAIL PROTECTED] wrote:
If I understand correctly:
> Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0
This NOP (deletion?) creates another set of potential uses - as now
the > prior RHS def now passes straight thru to a new set of uses - but
we > miss those new uses. (which in the testcase are often 0)
> I will try fwprop in a few different spots latter and see what, if
any > changes occur.
Classic cascading.
I think some of this is an artifact of how your splitters are working.
You end up creating code which looks like
(set (reg1) (const_int 0)
(set (reg1) (ior (reg1) (other_reg)
What's important here is that reg1 is being set multiple times. You'd
be better off if you can twiddle the splitters to avoid this behavior.
If you need a new pseudo, then get one :-)
Once you do that, local would propagate these things better. That
still leaves the simplification & nop problem, but I'm pretty sure
that can be trivially fixed within local without resorting to running
another forwprop pass after splitting.
Jeff
________________________________________________________________________
More new features than ever. Check out the new AIM(R) Mail ! -
http://webmail.aim.com
