Re: Question on fixup_abnormal_edges

[Olivier Hainque <hainque@ACT-Europe.FR>]

Hello Jan,

Back on a somewhat old issue :)

Jan Hubicka wrote:
> some pass in the way updates the information incorrectly - 347
> should really be dead.  Can you figure out where it appears live first
> time?

I have a better understanding of what's happening. Some aspects are
still unclear, though, so here is a short summary followed by a question:

From a .life dump, part of the cfg looks like:

                              ab,
                              abcall,
            ft        ft      eh
    43     ----> ... ----> 50 ----> 51 ----> 53
     |                      |                 |
  set 347               noreturn           read 347
                          call

  347 becomes live at the start of block 53, and remains live all the way
  up (left) to block 43, with an EH_EDGE in between.

  I saw a number of protections in the register allocation machinery to 
  prevent the allocation of hard regs to pseudos live across calls if there
  are nonlocal labels around. 

  However, as we are working on table driven EH (no setjmp/longjmp), 
  has_nonlocal_label stays false, and global_alloc eventually assigns a
  hard reg to 347. This turns out to be a call clobbered reg, later handled
  by caller_save with the consequences we know (SEGV in fixup_abnormal_edges).


What I'm first unclear about is:

  When using table driven EH, is it expected that possibly call clobbered hard
  registers get assigned to pseudos live across calls like in the case above ?

Thanks in advance for your help,

Kind Regards,

Olivier