Re: Redundant logical operations left after early splitting

[hutchinsonandy at aim dot com]

Jeff,

thanks for help - I desparately need ideas - this problem is driving me 
nuts

The RTL for IOR Rx,0 does use subregs  (since I use simplify_gen_subreg 
in splitter.)

Perhaps I should  generate new pseudo QI registers instead before 
reload?

Is there any particular function or pass that should be dealing with 
IOR rx,0 - that I could trace thru and figure out why it does not like 
it (or never gets there)?

Andy



-----Original Message-----
From: Jeff Law <law@redhat.com>
To: hutchinsonandy@aim.com
Cc: gcc@gcc.gnu.org
Sent: Tue, 19 Feb 2008 2:12 pm
Subject: Re: Redundant logical operations left after early splitting


hutchinsonandy@aim.com wrote:Â
> > I am stumped and hope someone more skilled can give me some clues 
to > solve this problem I have 4.3/4.4 gcc.Â
> > I have created RTL define/splits for AVR port logical operation 
(AND,IOR > etc). These split larger mode operations in to QImode 
operations. I also > created similar splitters for zero_extend and some 
combined > zero_extended shift operations.Â
> > All of these create QImode moves of subregs and all split before 
reload > (ie unconditional).Â
> > They all split as expected at first oppertunity and produce 
expected > RTL. Whoppee!Â
> > When code involves zero constants (created by zero_extend, or 
shift) I > can see propagation of constant into following logical 
operations. (Os > or O3 optimizations). Such as:Â
> > Rx = 0Â
> OR Ry,RxÂ
> > becomingÂ
> > OR Ry,0Â
> > The propagation is fine, BUT the creation of OR Ry,0 is a totally > 
redundant operation and remains intact thru all further passes into > 
final code - apparently not being removed by any optimisations after > 
split1 pass!Â
> > I created RTL pattern to remove these (splitting OR Rx,0 into NOP) 
and > that removes them - but surely this workaround should not be 
needed. I > am stumped by what could be causing the problem. Help!Â
> > There also seem to be cases where zero constants are not propagated 
into > instructions. Yet testcase only involves simple operands, no 
loops or > conditionals or any other side effects that might be reason 
to block > this. Can anyone suggest some non-obvious reasons for this?Â
You'll need to look at the RTL dumps to determine why these redundantÂ
operations are not being removed or why some propagations aren't beingÂ
performed.Â
Â
GCC certainly has code to do things like remove X IOR 0, so you justÂ
need to figure out why it isn't triggering. If your code had lots ofÂ
SUBREGs, then that's definitely worth investigating -- many of GCC'sÂ
optimizers aren't particularly adept at dealing with SUBREGs.Â
Â
jeffÂ


________________________________________________________________________
More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com