Re: Redundant logical operations left after early splitting

[hutchinsonandy at aim dot com]

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 <law@redhat.com>
To: hutchinsonandy@aim.com
Cc: bonzini@gnu.org; gcc@gcc.gnu.org
Sent: Mon, 25 Feb 2008 4:34 am
Subject: Re: Redundant logical operations left after early splitting


hutchinsonandy@aim.com 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