Re: IA64 bootstrap failure

[Jan Hubicka <jh at suse dot cz>]

> >I've been looking at the code and what happens is that scheduler updates
> >CFG and then IA-64 hook jumps in and messes it up.  I can fix that in
> >case this is usefull for IA-64 port.
> 
> It is more complicated than that.  The IA-64 port adds instructions to carry
> out-of-band info that the CFG code doesn't understand.
> 
> For instance, search for control_flow_insn_p in verify_flow_info.  It calls
> error if it finds a control flow insn inside a basic block.  However, if
> you add the special IA-64 insns into the CFG, then we can have padding nops
> and/or stop bits after a control flow insn.  There is a fundamental conflict
> here.  Either we no longer end a basic block with a branch, or we stop using
> regular insns for this info, or we don't put the special IA-64 isnsns into the
> CFG.  I think the first option is a bad choice, and I don't see any real
> benefit to the second choice, so the third option seems best for now.  Thus
> I think we just need to avoid calling verify_flow_info during or after
> MACHINE_DEPENDENT_REORG.

Yes, that is what my patch made - CFG is updated correctly for using ebb
scheduler in toplev.c for "usual targets" and for IA-64 we simply update
it and then mess it up immediately by adding the instructions.
It does not matter, as I've removed the verify_flow_info call from
schedule_ebbs.  I will insert one just after scheduler in toplev.c once
the patch for enabling it there is reviewed.

I think we don't need CFG representations of the instruction chain with
stop bits and nops as it makes no sense to do any extra optimizations
that benefits from CFG, so I think current situation is fine for both
worlds.

Honza
> 
> I suppose building the CFG wrong to make verify_flow_info happy is another
> choice, but I also think that is a bad choice.
> 
> Jim