[RFC,PATCH] Still problems with move loop invariant and eh regs (#24762)

Ian Lance Taylor iant@google.com
Tue Jul 18 15:33:00 GMT 2006


Andreas Krebbel <krebbel1@de.ibm.com> writes:

> The df framework already contains code to take care of eh registers.
> df_bb_refs_record creates in df-scan.c:1666 artificial defs for
> the eh registers. But if - as on s390 - the eh registers are
> call-saved dw2_build_landing_pads emits clobbers for each of these
> registers at the beginning of every landing pad. These clobbers kill
> (in df_chain_create_bb) the use-def chains from eh reg uses to the 
> artificial definitions. What is left for check_dependencies in
> loop-invariant.c are uses of the eh regs without a definition.

If I understand this correctly, then the problem is that although
dw2_build_landing_pads has inserted a clobber, the registers are not
actually clobbered.  They actually contain meaningful values which
were set by the exception handling library routines.

The DF code should record this correctly.  So it seems to me that we
should not emit the CLOBBERs, and should instead modify flow to also
record this correctly (temporarily, until we remove flow in favor of
df).  That would probably mean adding something like this at the end
of propagate_block:

#ifdef EH_RETURN_DATA_REGNO
  bool has_eh_preds = false;
  FOR_EACH_EDGE (e, ei, bb->preds)
    {
      if (e->flags & EDGE_EH)
        {
          has_eh_preds = true;
          break;
        }
    }
  if (has_eh_preds)
    {
      unsigned int i;
      for (i = 0; ; ++i)
	{
	  unsigned regno = EH_RETURN_DATA_REGNO (i);
          int needed_regno;
	  if (regno == INVALID_REGNUM)
	    break;
          needed_regno = REGNO_REG_SET_P (pbi->reg_live, regno);
          if (pbi->local_set)
            {
              CLEAR_REGNO_REG_SET (pbi->cond_local_set, regno);
              SET_REGNO_REG_SET (pbi->local_set, regno);
            }
          if (needed_regno)
            SET_REGNO_REG_SET (pbi->new_set, regno);
          regs_ever_live[regno] = 1;
	}
    }
#endif


No doubt there are additional complexities, though.

Ian



More information about the Gcc-patches mailing list