[rfc] multi-word subreg lowering pass
Michael Matz
matz@suse.de
Fri Jun 2 16:27:00 GMT 2006
Hi,
On Thu, 1 Jun 2006, Ian Lance Taylor wrote:
> I've also been working on this. I'm currently running a version of
> RTH's lower-subreg pass twice, once early and once after splitting
> instructions. Then I've added splits for, e.g., adddi3. This gives me
> good results, including results like the ones you showed. In order to
> improve real benchmarks, though, I still have some more work to do,
> specifically to enhance the register allocators to understand that
> DImode copies represented as two SImode copies do not indicate a
> register conflict
If I understood you correctly you are thinking about this situation:
Initially
p1:DI <-- some expression
p2:DI <-- p1:DI ; p1 dies, hence p1 and p2 do not conflict
use <-- p2:DI
is transformed into (p1->(p10,p11) , p2->(p20,p21))
p10:SI <-- some exp1
p11:SI <-- some exp2
p20:SI <-- p10:SI ; p10 dies
p21:SI <-- p11:SI ; p11 dies
use1 <-- p20:SI
use2 <-- p21:SI
p10 and p11 must conflict anyway, as must p20 and p21, and they do with
the normal conflict graph builder. That one will also create a conflict
between p11 and p20 (not between p10 and p21, though). Are you worried
about that one? Generelly you can not do without that conflict, because
if you don't have it, they might get the same register, and then p11 would
be clobbered by writing to p20. To be able to do without this conflict
you need to ensure certain conditions on how p10/p11 and p20/p21 are layed
out in the end, but those would again just implicitely capture the effect
of the conflict edge, namely that the ex-high part conflicts with the
ex-low part of a multi-word reg.
Note that this p11-p20 conflict does not prevent you from coalescing both
copies away, I guess that's what you are interested in. p11 doesn't
conflict with p21, so they can be merged, as can p10 and p20. So
everything just works as expected without any special handling of the
conflicts. But perhaps I'm misunderstanding what you tried to achieve.
Ciao,
Michael.
More information about the Gcc-patches
mailing list