[PATCH] D105097: [clang][AArch64][SVE] Handle PRValue under VLAT <-> VLST cast

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.


================
Comment at: clang/lib/CodeGen/CGExprScalar.cpp:2120
+      } else
+        Addr = EmitLValue(E).getAddress(CGF);
       Addr = Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(DestTy));
----------------
junparser wrote:
> junparser wrote:
> > efriedma wrote:
> > > I don't think it's legal to use EmitLValue here at all; the emitted IR could have side-effects.
> > > 
> > > Since we have the vector insert/extract intrinsics now, can we just use them here instead of going through the load/store dance?
> > > I don't think it's legal to use EmitLValue here at all; the emitted IR could have side-effects.
> > > 
> > I agree since we have already visited E. 
> > 
> > > Since we have the vector insert/extract intrinsics now, can we just use them here instead of going through the load/store dance?
> > 
> > we have already use insert/extract intrinsics for same element type, we can only handle predicate cast through memory.
> > One of idea here is always use store + load. what do you think?
> > 
> @efriedma I'm also working on a patch that optimize such store + bitcast + load pattern with constant vector, so maybe it is ok to always use alloca + load
I'd be happy to accept just unconditionally doing the alloca+store+load thing for now.

Not sure I understand why predicates are special here.  Even if we can't handle predicates directly in insert/extract intrinsics, we can always just zero-extend to a bigger integer type, do the cast, then truncate the result.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105097