Re: final cfg build problems

[Richard Earnshaw <rearnsha at arm dot com>]

law@cygnus.com said:
> First, I think some ports (sh, arm/thumb, mips16?) use machdep_reorg
> to place constant pools within certain ranges of particular
> instructions.  We have to be careful not to muck up those placements
> when we call the cfg builder since it can move blocks around.

Definitely.  Once machdep_reorg has run on the ARM/Thumb port, it would be 
fatal to move any insns around that change the size calculations and 
placements of insns.  The code works at a function level on the insn chain 
so that a minimal number of constant pools are created; it will even break 
up a single block into two or more smaller ones if necessary (further, we 
don't even update the bb records for this, since in the past this was 
never necessary).  We don't even generate block records for the constant 
pools inserted (maybe we should, but I'm not sure what use they would be).

The ARM does not have branch delay slots so dbr_schedule is not run, but 
it could be nasty if the CFG is altered.

When compiling for the ARM (but not thumb) we do have predicated insns.  
Currently we handle these with a simple bit of code in FINAL_PRESCAN_INSN, 
but it would be nice to push this into a more comprehensive analysis of 
the CFG if there were a way of representing the results in the RTL (the 
technique used to hold branch-delay-slot instructions isn't really 
suitable, since it can't really handle variable length sequences or 
control dropping into the middle of a sequence).  Altering the CFG after 
such a pass has run would also be nasty, since whether such an 
optimization is worth doing is critically dependent on the length of the 
sequence so optimized.

Is there a good reason why dbr_schedule has to run *after* machdep_reorg?

R.