On 08/22/14 06:21, Ilya Enkovich wrote:
Such approach worked well on small tests but trying to run some
benchmarks we faced a problem with reload of address constants. The
problem is that when we try to rematerialize address constant or some
constant memory reference, we have to use pic_offset_table_rtx. It
means we insert new usages of a speudo register and alocator cannot
handle it correctly. Same problem also applies for float and vector
constants.
Isn't this typically handled with secondary reloads? It's not an exact
match, but if you look at the PA port, you can see cases where we need
to have %r1 available when we rematerialize certain constants. Several
ports have secondary reloads that you may be able to refer back to. LRA
may handle things differently, so first check LRA's paths.
Rematerialization is not the only case causing new
pic_offset_table_rtx usage. Another case is a split of some
instructions using constant but not having proper constraints. E.g.
pushtf pattern allows push of constant but it has to be replaced with
push of memory in reload pass causing additional usage of
pic_offset_table_rtx.
Yup. I think those would be handled the same way.
Jeff
