Redundant logical operations left after early splitting

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