This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Use of build_binary_op
On Thu, 26 Sep 2002 13:19:44 +0200, Pop Sébastian <pop@gauvain.u-strasbg.fr> wrote:
> I have not yet looked at the inliner code, but I have a question:
> does the inliner work on the simplified version of GENERIC or just
> on GENERIC trees?
Actually, it can probably inline into most anything, since it is just
replacing a CALL_EXPR with a BIND_EXPR. The inline function can't be in C
frontend trees, because of the _STMT business, but if there are still
expression-level frontend trees, that shouldn't be a problem.
IOW, GENERIC doesn't actually need to be completely generic. I think the
only constraints for the inliner are that scopes are represented using
BIND_EXPR and returns with RETURN_EXPR. And, of course, it will only
inline calls that are represented using CALL_EXPR; if I were to, say, delay
lowering/translating C++ new-expressions, the inliner wouldn't see the
calls to operator new and the constructor.
This seems like a reasonable model, actually; the initial tree IL can have
frontend constructs present, subject to some minor constraints. The
inliner, mudflap, and any frontend-specific optimizers operate on this
representation, which corresponds roughly to Very High WHIRL. Then we
simplify, which removes any frontend trees so that dataflow doesn't have to
worry about them.
Jason