This is the mail archive of the
mailing list for the GCC project.
Re: Patch to fix incorrect hard register life information
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: Patch to fix incorrect hard register life information
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sat, 05 Sep 1998 14:21:00 -0600
- cc: Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <email@example.com>you write:
> The last block sets two registers and returns to a magic label, the eh
> stub, which then adjusts sp and jumps to the handler.
> The important bit is the setting of the registers. flow needs to know that
> the registers are live at the end of the last block, which can be handled
> with USE insns (right?). It also needs to know that they are set coming
> into the eh stub. Can this be handled with CLOBBERs?
Probably. But this is dangerous.
If we are missing an edge in the cfg, then the gcse code may make an
For example, say there is some expression in the eh stub which happens
to be computed elsewhere in the function and is available on a path
with an edge to the stub (and remember, the cfg has an edge from the
insn with the REG_LABEL note to the eh stub).
Also assume that the expression is *not* available on the path from
the end of the function to the eh stub.
gces will delete the evaluation of the expression in the eh stub.
However since it does not see the edge from the end of the function
to the stub, no evaluation of the expression is inserted on that path.
Thus if we end up taking the path from the end of the function to the
eh stub, the partially redundant expression will not be evaluated
resulting in incorrect code.
I don't know enough about the code in question to know if this can
ever happen. But even trivial stuff like an address calculations,
memory loads, etc are subject to gcse/pre optimizations, so I'd be
very careful declaring this isn't an issue for __throw.