On 03.04.2012 13:36, Jakub Jelinek wrote:
On Mon, Apr 02, 2012 at 06:56:25PM +0400, Andrey Belevantsev wrote:
After Richi's RTL generation related cleanups went it, the extra
cleanup_cfg call was added so we are no longer lucky to have the
proper fallthru edge in this case.  The PR trail has the patch to
purge_dead_edges making it consider this situation, but I still
prefer the below patch that fixes only the invalid asm case.  The
reason is that I think it unlikely that after initial RTL expansion
(of which the instantiate virtual regs pass seems to be the part) we
will get the problematic situation.  However, I'm happy to test the
PR trail patch, too.


I don't like blindly changing edge into FALLTHRU, generally the edge
could be abnormal, or EH, etc. and making that fallthru is not a good idea.
I'd prefer if wherever the fallthru edge is removed the other normal edge(s)
are adjusted.

Well, as I mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106#c18 the removal happens in try_optimize_cfg around line 2617, that's the code that deals with removing trivially empty block (in the PR case, the succ of the asm goto block is trivially empty). After that we have an asm goto acting as an unconditional jump with a single succ edge and no fallthru bit, which seems perfectly fine. We get into trouble when we actually realize that the asm is bogus. Thus I've tried to fix it up at this time. The options that we briefly discussed on IRC with Richi are as follows:

- Fix up try_optimize_cfg in the case of asm gotos, but it is not clear to me how do we do this -- we don't yet distinguish between good and bad asm goto at this point;

- Fix up function.c as I did but make it more robust. Either handle more cases with strange edges (EH seems also possible after introducing the throw attribute for asms), or just remove the asm and insert the unconditional jump pointing to the place where the asm was, retaining all the flags;

- Fix up purge_dead_edges. as I did initially in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106#c16. When we find a situation of no jump at the end of block and no fallthru edge, assert this happens only with single_succ_p and actually make this edge fallthru. (Probably also watch out whether we need to make it fake or whatever.) Or as Richi tried, just accept the situation of having no successors here, as in -- no fallthru edge on entry to purge_dead_edges and no jump means no successors, period.

I think that just nobody deleted unconditional jumps with delete_insn_and_edges previously, otherwise I don't understand why this did not trigger.

Thoughts?

Andrey


        Jakub

Reply via email to