Displaying 5 results from an estimated 5 matches for "findmemtype".
2012 Feb 29
2
[LLVMdev] Expand vector type
...ned by LLVM to a vec4. Stores are kind of funny. By default LLVM sets the action to 'widen' but in GenWidenVectorStores what ends up happening is an 2:1 split of the vector that's less efficient in this case than actually widening the vector. The reason is that at this point the call to FindMemType assumes that stores can never be widened to a bigger type and so those types are not considered. The call sequence I'm looking at is WidenVectorOperand() -> WidenVecOp_STORE() -> GenWidenVectorStores() -> FindMemType(). I've made a very small modification to enable support for wide...
2012 Feb 29
2
[LLVMdev] Expand vector type
...havior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType().
If my analysis is correct then your v316 STOREs are being broken into multiple ones depending on ARM NEON support. Can you please confirm?
Thanks,
Javier
From: James Molloy [mailto:james.molloy at arm.com]
Sent: Wednesday, February 29, 2012 2:35 AM
To: Martinez, Javier E; llvmdev at cs.uiuc.e...
2012 Mar 05
1
[LLVMdev] Expand vector type
...omote. This means that for example a call to
> DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON
> returns TypeWidenVector. From here legalization calls WidenVectorOperand() to
> process the STORE node and follows the call chain I have on my original email to
> FindMemType().
>
> If my analysis is correct then your v316 STOREs are being broken into multiple
> ones depending on ARM NEON support. Can you please confirm?
>
> Thanks,
>
> Javier
>
> *From:*James Molloy [mailto:james.molloy at arm.com]
> <mailto:[mailto:james.molloy at arm....
2012 Mar 05
0
[LLVMdev] Expand vector type
...havior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType().
If my analysis is correct then your v316 STOREs are being broken into multiple ones depending on ARM NEON support. Can you please confirm?
Thanks,
Javier
From: James Molloy [mailto:james.molloy at arm.com]<mailto:[mailto:james.molloy at arm.com]>
Sent: Wednesday, February 29, 2012 2:35...
2012 Feb 29
0
[LLVMdev] Expand vector type
...ned by LLVM to a vec4. Stores are kind of funny. By default LLVM
sets the action to 'widen' but in GenWidenVectorStores what ends up
happening is an 2:1 split of the vector that's less efficient in this case
than actually widening the vector. The reason is that at this point the call
to FindMemType assumes that stores can never be widened to a bigger type and
so those types are not considered. The call sequence I'm looking at is
WidenVectorOperand() -> WidenVecOp_STORE() -> GenWidenVectorStores() ->
FindMemType(). I've made a very small modification to enable support for
wide...