Demikhovsky, Elena
2014-Dec-14 15:08 UTC
[LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
Hi, I think that def FeatureVectorUAMem : SubtargetFeature<"vector-unaligned-mem", "HasVectorUAMem", "true", "Allow unaligned memory operands on vector/SIMD instructions">; should be switched-ON on AVX and AVX-512 instructions because: According to the AVX spec: "Most arithmetic and data processing instructions encoded using the VEX prefix and performing memory accesses have more flexible memory alignment requirements than instructions that are encoded without the VEX prefix. Specifically, * With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions, most VEX-encoded, arithmetic and data processing instructions operate in a flexible environment regarding memory address alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load semantics will support unaligned load operation by default. Memory arguments for most instructions with VEX prefix operate normally without causing #GP(0) on any byte-granularity alignment (unlike Legacy SSE instructions)." And the same for AVX-512. We do not require any alignment while folding loads on the "Peephole Optimizations" on these targets. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141214/8a01dde7/attachment.html>
Chandler Carruth
2014-Dec-14 22:26 UTC
[LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
FWIW, this makes sense to me. I'd be interested to hear from folks that are supporting AMD processors which do support AVX to ensure that there isn't an undue runtime penalty for these. On Sun, Dec 14, 2014 at 7:08 AM, Demikhovsky, Elena < elena.demikhovsky at intel.com> wrote:> > Hi, > > I think that > def FeatureVectorUAMem : SubtargetFeature<"vector-unaligned-mem", > "HasVectorUAMem", "true", > "Allow unaligned memory operands on vector/SIMD > instructions">; > > should be switched-ON on AVX and AVX-512 instructions because: > > According to the AVX spec: > “Most arithmetic and data processing instructions encoded using the VEX > prefix and > performing memory accesses have more flexible memory alignment requirements > than instructions that are encoded without the VEX prefix. Specifically, > • With the exception of explicitly aligned 16 or 32 byte SIMD load/store > instructions, > most VEX-encoded, arithmetic and data processing instructions operate in > a flexible environment regarding memory address alignment, i.e. VEX-encoded > instruction with 32-byte or 16-byte load semantics will support unaligned > load > operation by default. Memory arguments for most instructions with VEX > prefix > operate normally without causing #GP(0) on any byte-granularity alignment > (unlike Legacy SSE instructions).” > > And the same for AVX-512. > > We do not require any alignment while folding loads on the “Peephole > Optimizations” on these targets. > > > > > - * Elena* > > > > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141214/c8ce3066/attachment.html>
Das, Dibyendu
2014-Dec-15 05:00 UTC
[LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
AFAIK, there is no additional penalty for AMD processors. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth Sent: Monday, December 15, 2014 3:57 AM To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets FWIW, this makes sense to me. I'd be interested to hear from folks that are supporting AMD processors which do support AVX to ensure that there isn't an undue runtime penalty for these. On Sun, Dec 14, 2014 at 7:08 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>> wrote: Hi, I think that def FeatureVectorUAMem : SubtargetFeature<"vector-unaligned-mem", "HasVectorUAMem", "true", "Allow unaligned memory operands on vector/SIMD instructions">; should be switched-ON on AVX and AVX-512 instructions because: According to the AVX spec: “Most arithmetic and data processing instructions encoded using the VEX prefix and performing memory accesses have more flexible memory alignment requirements than instructions that are encoded without the VEX prefix. Specifically, • With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions, most VEX-encoded, arithmetic and data processing instructions operate in a flexible environment regarding memory address alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load semantics will support unaligned load operation by default. Memory arguments for most instructions with VEX prefix operate normally without causing #GP(0) on any byte-granularity alignment (unlike Legacy SSE instructions).” And the same for AVX-512. We do not require any alignment while folding loads on the “Peephole Optimizations” on these targets. · Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141215/e54b18c5/attachment.html>