Splitting call_insns
Alexandre Oliva
aoliva@redhat.com
Thu Nov 23 06:16:00 GMT 2000
Even though this patch fixes a SH-specific problem, there is one fix
in generic code (emit-rtl.c), so I'll need approval from someone with
global write privileges.
The problem, as NIIBE Yutaka observed, is that we've abused
CODE_LABELs to emit PC-relative calls. A simple testcase that
demonstrates the problem is included in the patch below.
The solution, proposed originally by Richard Henderson, then partially
implemented by Yutaka-san (or should it be NIIBE-san; sorry, I don't
know :-(, was to create an intermediate call pattern, that would only
be split after all loop optimizations, so we would generate one label
for each call site. For some reason, the original test on
`!flag_unroll_loops' to decide whether to emit a PC-relative call
didn't work; we seem to be doing some loop unrolling even when
-funroll-loops isn't given. I haven't investigated it any further.
Anyway, this new approach is far superior, since we won't disable it
just because loop unrolling is enabled. However, we won't do
PC-relative calls if optimization isn't enabled, because otherwise the
intermediate call pattern would be split too late. Without
optimization, we'll take the function address from the GOT. No big
deal, since it's not supposed to be efficient anyway :-)
I had to adjust emit-rtl.c so as to propagate function usage
information from the a split insn into call insns that appear in the
generated SEQ.
It turned out that the new predicate symbol_ref_operand was necessary,
after all. immediate_operand isn't suitable because, even though it
accepts SYMBOL_REFs, it checks whether the operand is a valid
constant, but, when generating PIC, we don't accept SYMBOL_REFs as
valid constants.
No regressions on sh-elf (m3, m3e, m4 and m4/ml) both with and without
-fPIC. Ok to install?
More information about the Gcc-patches
mailing list