This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Improve code generated by cmpstrsi patterns
>
> In message <20000717184027.F5039@atrey.karlin.mff.cuni.cz>you write:
> > >
> > > Supposing I added code to combine to permit arbitrary no-op moves,
> > > even if unrecognizable; would it be unsafe to run jump_optimize with
> > > noop_moves 1 immediately afterward? (I guess I'm really asking if
> > > it's unsafe to run delete_noop_moves before register allocation.)
> >
> > I don't think you can run jump pass after combine w/o disturbing
> > the flow information required by register allocator.
> > Some more curefull method of removing dummy sets would be needed...
> That is correct at the time being. However, one can imagine fixing that
> little problem with incremental updates to the cfg and life data. Or
> since I expect this is a rare case you could even consider re-running
> cfg detection & life analysis. [ Then again, it may be rare enough to
> not be worth the effort, though typically if we can zap a conditional
> jump I consider it worth doing).
OK. This sounds sane.
Slow moving jump into cfg-cleanup pass is on my long TODO list too. Perhaps
this one is good motivation to start and implement that simple bit to CFG
cleanups. Later others cen be added so jump pass can be gradually replaced.
I will write routine for merging blocks that lost their condjumps soon and
try to move no-op zapping code to the CFG cleanup as well (this should need
very little effort).
> We have a subset of the du chains; building the chains from SSA information
> has been something I've wanted ever since I grasped what SSA really was.
Yep...
Honza
>
>
> jeff