[PATCH] D57871: Fix some cases where icmp (bitcast ([su]itofp X)), Y is misfolded

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 6 23:48:37 PST 2019


craig.topper added inline comments.


================
Comment at: test/Transforms/InstCombine/cast-int-icmp-eq-0.ll:665-666
+;
+  %f = sitofp <3 x i16> %i to  <3 x float>
+  %b = bitcast <3 x float> %f to <6 x i16>
+  %cmp = icmp sgt <6 x i16> %b, <i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1>
----------------
lebedev.ri wrote:
> I agree that this currently crashes, but are you sure this is valid in the first place?
> `%f = sitofp <3 x i16> %i to  <3 x float>` implies that `sizeof(float)` == `sizeof(i16)`
> `%b = bitcast <3 x float> %f to <6 x i16>` implies that `sizeof(float)` == `2*sizeof(i16)`.
> How can `bitcast` do that?
> 
> https://llvm.org/docs/LangRef.html#bitcast-to-instruction
> > The bit sizes of value and the destination type, ty2, must be identical.
> > It is always a no-op cast because no bits change with this conversion.
> > The conversion is done as if the value had been stored to memory and read back as type ty2. 
sizeof(float) is always 32 bits. Why does sitofp <3 x i16> %i to  <3 x float> imply sizeof(float) == sizeof(i16)? There's no requirement that the integer and fp width be equal for that.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57871/new/

https://reviews.llvm.org/D57871





More information about the llvm-commits mailing list