This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

SAVE_EXPR and sibling calls


I was thinking about this a bit.  Sibling call optimization is important,
but only does something for a very small fraction of calls.  Most call
operands are simple (variables or simple expression), only a fraction of
which have side-effects and only a tiny number of which have SAVE_EXPR.
I'd guess that the number of converted sibling calls whose operands have
SAVE_EXPRs is close to zero.

So why bother with them?  Why not just suppress the optimization if there's
an operand that has a SAVE_EXPR?

And if we *don't* want to do that, we can enclose the whole thing in another
SAVE_EXPR and evaluate *that* outside of the two insn streams we generate:
since we know that exactly one will actually be used, we're fine.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]