[PATCH] D15392: [InstCombine] fold trunc ([lshr] (bitcast vector) ) --> extractelement (PR25543)

[hfinkel@anl.gov via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D15392#307685, @spatel wrote:

> To take this to its logical (I hope) conclusion...
>  We shouldn't need the transform in http://reviews.llvm.org/D14879 at all if we:
>
> 1. Canonicalize bitcasts before extractelements
> 2. Transform (bitcast (bitcast X)) --> bitcast X
>
>   I'm not sure why we wouldn't allow the 2nd for any types, but CastInst::isEliminableCastPair() says we're not allowed to simplify those if vector and scalar types are intermingled and it's not a roundtrip to the original type: // If either of the casts are a bitcast from scalar to vector, disallow the // merging. However, bitcast of A->B->A are allowed.


I've added Nadav, in case he remembers what this is all about. It seems to have been related to a fix to:

  https://llvm.org/bugs/show_bug.cgi?id=7311

see also:

  http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110829/127115.html
  http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110829/127089.html

and while I'm not 100% sure, I suspect that limitation in isEliminableCastPair is to prevent constant folding from creating illegal instructions (like uitofp i64 %x to <2 x float>) more than any underlying statement about the semantics of bitcasts. Thus, the current limitations in instcombine seem like an unfortunate accident more than some purposeful design.

I think that the canonicalization you propose makes sense.

> ...



http://reviews.llvm.org/D15392