> This doesnt happen because while inserting the caller save insn, its
> live_throughout is simply set to the live_throughout of the call insn
> + the registers marked with REG_DEAD notes in the call insn.

Ouch.  Relying on REG_DEAD notes to get complete liveness info is a no-no:

/* The value in REG dies in this insn (i.e., it is not needed past
   this insn).  If REG is set in this insn, the REG_DEAD note may,
   but need not, be omitted.  */
REG_NOTE (DEAD)

This problem was apparently introduced a long time ago:
  http://gcc.gnu.org/ml/gcc-cvs/1999-12/msg00212.html

> However since $c1 is an argument to the call it is used by the call_insn
> and is marked  REG_DEP_TRUE ( Read after Write).

Yes, and it's because it is also set in the insn (as return value register) 
that it doesn't get the REG_DEAD note; the 3 other argument registers do.

> Shouldnt regs in REG_DEP_TRUE be added to live_throughout. My suspicion is
> that the LOG_LINKS are not always up-to-date, therefore will it be
> better to use DF_INSN_UID_USES ?

DF is supposed to be out of the game at this point, it has handed over the 
control since global.c:build_insn_chain as far as liveness info is concerned.

The REG_DEP_TRUE are somewhat misleading, it's an artifact in the dump.
What you're seeing are the contents of CALL_INSN_FUNCTION_USAGE, which are 
always correct, so a solution to your problem would be to scan it for uses of 
registers in caller-save.c:insert_one_insn.  Of course this wouldn't plug the 
hole entirely but would very likely be sufficient in practice.

This problem doesn't seem to have already been reported, probably because the 
compiler is not supposed to be using the return value register for reloading, 
unless seriously under pressure.  Do you define REG_ALLOC_ORDER for your 
port?  If so, in what position is $c1?

-- 
Eric Botcazou

Reply via email to