[cfe-dev] Speculative load optimization

[Craig Topper via cfe-dev]

I think ternary is equivalent to an if in that only one side is evaluated.
But I think you're saying that gcc and icc will dereference s for both
sides of the if and then select between the loaded values.  Like this

    struct S* f1(struct S *s, int x)
    {
      struct S *a = s->p1;
      struct S *b = s->p2;
      return (x) ? a : b;
    }

~Craig

On Mon, Oct 9, 2017 at 2:16 PM, Kreitzer, David L via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> This llvm patch, https://reviews.llvm.org/D37289, attempts to do an
> optimization
> that involves speculating loads. The patch itself needs some work
> regardless,
> but we are questioning the legality of the optimization, which is currently
> performed by both gcc and icc. The desired transformation looks like this:
>
>     typedef struct S {
>       char padding[4088];
>       struct S *p1;
>       struct S *p2;
>     } S;
>
>     struct S* f1(struct S *s, int x)
>     {
>       S *r;
>       if (x)
>         r = s->p1;
>       else
>         r = s->p2;
>       return r;
>     }
>
> TO
>
>     struct S* f1(struct S *s, int x)
>     {
>       return (x) ? s->p1 : s->p2;
>     }
>
> The fundamental question seems to be whether loading one member of struct S
> makes it valid to load other members of the same struct. Both gcc & icc
> seem to think so and make a distinction between this case and a similar
> case
> where one field is accessed through an lvalue of a different type:
>
>     typedef struct T {
>       char padding[4088];
>       struct S *p1;
>     } T;
>
>     struct S* f2(struct S *s, int x)
>     {
>       S *r;
>       if (x)
>         r = ((T*)s)->p1;
>       else
>         r = s->p2;
>       return r;
>     }
>
> Neither compiler will transform this case.
>
> Any insight on the validity of this optimization in relation to the C/C++
> standards would be appreciated.
>
> Thanks,
> Dave Kreitzer
> Intel Compilers
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171009/aaa01aa1/attachment.html>