[PATCH] Make SROA handle addrspacecast

[Sanjoy Das]

================
Comment at: lib/Transforms/Scalar/SROA.cpp:1825
@@ +1824,3 @@
+  if (Ptr->getType() != PointerTy) {
+    Ptr = IRB.CreatePointerBitCastOrAddrSpaceCast(Ptr, PointerTy,
+                                                  NamePrefix + "sroa_cast");
----------------
jingyue wrote:
> chandlerc wrote:
> > sanjoy wrote:
> > > Will this transform a "gep(addrspacecast X), Y)" to "addrspacecast(gep X, Y')"?  If so, I think we need a target specific hook that does a legality check on the addrspacecast we're about to insert -- I don't think "addrspacecast X" is legal implies an addrspacecast on a GEP derived from X is also legal.
> > The whole point of addrspacecast was to avoid the need for target specific checks... I think we just shouldn't transform GEPs around them if that isn't legal everywhere.
> Thanks for pointing this out, Sanjoy. I understand your concerns. Curiously, on which existing targets such transformation from `gep(addrspacecast X), Y` to `addrspacecast(gep X, Y)` is illegal? Just asking so that I can keep a concrete example in mind when I later write target-independent optimizations on addrspacecast. 
In practice, I think `gep(addrspacecast X), Y` and `addrspacecast(gep X, Y)` should compute the same result in all existing targets.  However, this caps how complex an `addrspacecast` implementation can be.  For instance, targets won't be able to implement `addrspacecast` as

```
addrspacecast(P) { return abs(P) }
```

since with this change, `gep(addrspacecast(-1), 2)` != `addrspacecast(gep -1, 2)`.

I'm okay with moving ahead with this gep transform as long as we change the langref to reflect that `addrspacecast` instructions cannot be arbitrarily complex value modifications (so that an `abs` implementation for `addrspacecast` can be ruled out).

http://reviews.llvm.org/D10482

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/