New cfg code

Jeffrey A Law law@cygnus.com
Tue Aug 31 23:20:00 GMT 1999


  In message < 19990803023059.A27430@cygnus.com >you write:
  > Nr 2 is my preferred short-term solution.
That's the direction I was leaning.  

  > Long term, of course,
  > we've got to get rid of ADDR_VEC as an instruction completely.
  > Probably by hanging a SEQUENCE containing the interesting label
  > and ADDR_VEC off of a reg note on the tablejump insn.
Yup.

  > Nr 1 pollutes CSE with stuff it shouldn't be having to think about.
Yup.  And it's not any uglier to do it in jump.

  > Nr 3 results in uglier CFGs.
Yes.

  > Attached is a patch that allows the test to succeed.  It's not as
  > friendly as it might be, as optimization phase sequencing leaves
  > the (code_label 80) around much longer than I would have liked.
  > It is gone before final though, so it's not the end of the world.
Another approach I didn't mention was to run delete_trivially_dead_insns
after cse2.  That allows us to kill the final outstanding reference to the
label which in turn allowed flow to delete the label.  But I didn't 
particularly
like that approach :-)

  > 	* jump.c (delete_insn): Delete the addr_vec when deleting a tablejump.
I went ahead and installed this.

Thanks,
jeff



More information about the Gcc mailing list