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~