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