Re: RFC: objc_msgSend efficiency patch

[Richard Henderson <rth at redhat dot com>]

On Mon, Feb 21, 2005 at 05:07:30PM -0800, Dale Johannesen wrote:
> -           r0 = gimplify_expr (&OBJ_TYPE_REF_OBJECT (*expr_p), pre_p, 
> post_p,
> +           /* Postincrements in OBJ_TYPE_REF_OBJECT don't affect the
> +              value of the OBJ_TYPE_REF, so force them to be emitted
> +              during subexpression evaluation rather than after the
> +              OBJ_TYPE_REF. This permits objc_msgSend calls in 
> Objective
> +              C to use direct rather than indirect calls when the
> +              object expression has a postincrement.  */
> +           r0 = gimplify_expr (&OBJ_TYPE_REF_OBJECT (*expr_p), pre_p, 
> NULL,
>                                 is_gimple_val, fb_rvalue);
>             r1 = gimplify_expr (&OBJ_TYPE_REF_EXPR (*expr_p), pre_p, 
> post_p,

It is not sufficient to change just the one expression and not the other.

> However, I'm not sure whether the comment is accurate for C++.   Can 
> somebody rule on that?  Thanks.

Eh.  Making the change *does* put the OBJ_TYPE_REF in the right
position for the call in c++, but that's irrelevant for -O0.
C++ only makes real use of OBJ_TYPE_REF with optimization on.

Indeed, this problem is unique to objc with -fnext-runtime.

I do think that it's safe to change, since we're talking about
rvalues in both cases.

I also think that it's a performance neutral change for C++,
since OBJ_TYPE_REF is mainly used for vtables, and calls force
the queue to be flushed beforehand.  Thus while processing the
OBJ_TYPE_REF, the incoming post_p should always be null, and
thus pushing the null down into the subexpressions results in
nearly the same code.  In the couple of examples that I tried,
we wound up with the same number of temporaries, for instance.


r~