x86 sibling call stuff

[Richard Henderson]

On Sun, Mar 19, 2000 at 12:18:07PM -0800, Mark Mitchell wrote:
>   Right now, this test won't compile.  The reason is that a
> NOTE_INSN_EH_REGION_BEG note that gets created during an expand_call
> never makes it into the final instruction stream, even thow the END
> note does.  A sanity check in flow causes an abort.

The argument to g(f()) is expanded once while trying for a sibcall. 
We find out after the fact that there are cleanups pending and dump
the sequence.  All well and good.

The problem is that when we go to re-evaluate the argument for the
normal call sequence, we don't get the same sequence.  We get the call
to `f', but we don't get the same cleanups that we got the first time.

Here's where I run into trouble.  Do I understand correctly that the
TARGET_EXPRs are the bits that generate the cleanups and such?  It
appears as if the one immediately surrounding `f' only gets evaluated
once.  Which is mighty confusing.

>From here it appears that cp_unsave_r is somehow broken.  Either it
isn't resetting state it should, or the copy it performs is incomplete.
Certainly the SCOPE_STMT was different the second time around.

One can hack the problem by installing a function in lang_safe_for_unsave
that rejects codes above LAST_AND_UNUSED_TREE_CODE.  Which will notice
the STMT_EXPR or SCOPE_STMT and prevent the first expansion.



r~