Re: [PATCH 1/7] Add __builtin_speculation_safe_value

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Jul 25, 2018 at 8:03 PM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 24/07/18 18:26, Richard Biener wrote:
> > So, please make resolve_overloaded_builtin return a no-op on such targets
> > which means you can remove the above warning.  Maybe such targets
> > shouldn't advertise / initialize the builtins at all?
>
> So I tried to make resolve_overloaded_builtin collapse the builtin
> entirely if it's not needed by the machine, transforming
>
>   x = __b_s_s_v (y);
>
> into
>
>   x = y;
>
>
> but I can't see how to make any side-effects on the optional second
> argument hang around.  It's somewhat obscure, but if the user does write
>
>  x = __b_s_s_v (y, z++);
>
> then z++ does still need to be performed.
>
> The problem seems to be that the callers of resolve_overloaded_builtin
> expect just a simple value result - they can't, for example, deal with a
> statement list and just calling save_expr on the argument isn't enough;
> so I can't see an obvious way to force the z++ expression back into the
> token stream at this point.
>
> Any ideas?  The alternative seems to be that we must keep the call until
> such time as the builtins are lowered during expansion, which pretty
> much loses all the benefits you were looking for.

Use a COMPOUND_EXPR: (z++, y).  So,

 if (TREE_SIDE_EFFECTS (2ndarg))
  res = build2_loc (loc, COMPOUND_EXPR, type, 2ndarg, 1starg);
 else
  res = 2starg;

Richard.

>
> R.