RFA: improvement to if-conversion
Joern Rennecke
joern.rennecke@superh.com
Fri Jan 30 13:25:00 GMT 2004
[struct_equiv]
> It would be nice to generalize this with the existing cross-jumping
> code that also tries to do structural matching.
It certainly makes sense to look at the special cases that the
cross-jumping code handles; I see I missed some of these. I'm not
very happy about the way it handles REG_EQUAL notes, though. It
should only remove non-matching notes if the optimization goes ahead.
Looking for matching outgoing edges instead of linear control flow
merge could improve if-conversion in general. When I was working on
constructing a simple testcase, I first just constructed a plain 3-way
min function, but it got only one simple if-conversion because the
straight jumps to the function return caused the if-conversion to fail
to match.
The cross-jumping code has no need to keep track of an input register.
I don't know if it would benefit from tracking of equivalent local
registers. Would the added overhead in cross-jumping be acceptable?
What would be the right home for a basic block structual comparison
function used by if-convert and cross-jumping? rtlanal.c ? cfgrtl.c?
> > + x_local = (x_regno >= regno_block_max
> > + || (regno_block[x_regno].first == info->x_block
> > + && regno_block[x_regno].last == info->x_block));
>
> Why wouldn't noticing that they're dead on entry and dead on exit
> be just as good? Seems like that'd be easier than maintaining
> your own regno_block thingy.
I think full register liveness information would be harder to keep
up-to-date as if conversion progresses. This optimization only
comes into its own as you match blocks that have been previously
joined by if-conversion.
> Clearly this will need testing on more targets. If you do x86, then
> you should bootstrap with -march=i686 so that cmove is available.
I'll try that. If I read invoke.texi correctly, I want something like
bash-2.05$ make bootstrap BOOT_CFLAGS='-march=i686 -O2 -g' > boot.out 2>&1 &
.
More information about the Gcc-patches
mailing list