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

[JunMa via Phabricator via cfe-commits]

junparser added inline comments.


================
Comment at: clang/lib/CodeGen/CGExprScalar.cpp:2120
+      } else
+        Addr = EmitLValue(E).getAddress(CGF);
       Addr = Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(DestTy));
----------------
efriedma wrote:
> 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.
I'm not sure whether zext+cast+trunc to vxi1 can generate better code. I think it is better to handle this in llvm ir without extend and truncate, only bitcast and insert/extract 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105097