Splitting call_insns

Joern Rennecke amylaar@redhat.com
Fri Nov 24 16:58:00 GMT 2000


> 	* config/sh/sh-protos.h (symbol_ref_operand): Declare.

Again, I think this should be done in one of the gen* programs.
Well, you've already posted a patch for it.

> 	* config/sh/sh.md (UNSPEC_CALLER): New constant.
> 	(calli_pcrel, call_valuei_pcrel): Use PIC_REG.
> 	(call_pcrel, call_value_pcrel): New insn_and_splits.
> 	(call, call_value): Use them.
> 	(call_site): New expand.
> 	(sym_label2reg, symPLT_label2reg): Adjust to hold call_sites.
> 	* config/sh/sh.h (OUTPUT_ADDR_CONST_EXTRA) [UNSPEC_CALLER]:
> 	Output call_site label.
> 	(PREDICATE_CODES): Added symbol_ref_operand.
> 	* config/sh/sh.c (symbol_ref_operand): Define.

This is all right with me.  I mainly tried to spot interference with
the existing ports here.  I don't really know the pic code too well
to start with.

> 	* emit-rtl.c (try_split): Propagate CALL_INSN_FUNCTION_USAGE
> 	to CALL_INSNs in the split sequence.

I'm not quite sure this will always do the right thing.  Is the
CALL_INSN_FUNCTION_USAGE of the split input insn always right for the
split output insn?  Will there always be just one input and one output
call?

I remember I had to push the FPSCR mode switching for the SH4 from rtl
generation to after reload because combine mixed up different USEs of
FPSCR.  There was simply no suitable way to communicate to combine
which value should be found in FPSCR for the combined insn to be valid.

What happens if two calls and one reg-reg insn get combined and splitted
into two call insns?
Or can you proove that it can't happen?


More information about the Gcc-patches mailing list