[PATCH] D37289: [X86] Speculatively load operands of select instruction

[Lama via Phabricator via llvm-commits]

lsaba added a comment.

In https://reviews.llvm.org/D37289#857637, @spatel wrote:

> In https://reviews.llvm.org/D37289#857435, @lsaba wrote:
>
> > In https://reviews.llvm.org/D37289#857007, @spatel wrote:
> >
> > > I didn't look at the implementation, but why is it safe to speculate loads in these tests? I can create an example where one of the pointers in the select is unmapped, so speculating that load will crash in the general case.
> >
> >
> > The implementation handles a specific case where both operands of the select are GEPs into elements of the same struct, correct me if i'm wrong but this should be safe
>
>
> I don't see how being elements of one struct changes anything. Just because one pointer is dereferenceable does not make the other dereferenceable? You would need 'dereferenceable' metadata or some other means to know that either load is safe to hoist ahead of the select.
>
> You're proposing this transform as an x86-specific pass, so maybe I'm missing something. Is there some feature of x86 that makes speculating the load safe? I'm guessing no because I tested the example I was thinking of on x86, and this transform crashes there.


This is the transformation I am interested in doing:

struct S {

  int a;
  int b;

}

from:

foo (S* s, int x) {

  int c;
  if (x) 
    c = s->a;
  else
   c = s->b;

}

to:
foo (S* s, int x) {

  int c1= s->a;
  int c2 = a->b;
  c = x? c1 : c2;

}

I am assuming this transformation is legal in C for the given struct with the given types since the entire struct is allocated,  is my assumption wrong? the idea is to limit the pass to these cases ( I am uploading a patch to limit the current implementation more)


Repository:
  rL LLVM

https://reviews.llvm.org/D37289