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>
Demikhovsky, Elena
2014-Dec-15 11:44 UTC
[LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
Ok, if no objections, I’ll add “HasVectorUAMem” feature to all AVX processors.
I’ll allow to fold an unaligned load to instruction.
- Elena
From: Das, Dibyendu [mailto:Dibyendu.Das at amd.com]
Sent: Monday, December 15, 2014 07:01
To: Chandler Carruth; Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [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> [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<mailto: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
---------------------------------------------------------------------
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/20141215/c69535ac/attachment.html>
Das, Dibyendu
2014-Dec-15 12:11 UTC
[LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
Are there some test cases or micro bms u r planning to use ?
Sent from my Windows Phone
________________________________
From: Demikhovsky, Elena<mailto:elena.demikhovsky at intel.com>
Sent: 12/15/2014 5:16 PM
To: Das, Dibyendu<mailto:Dibyendu.Das at amd.com>; Chandler
Carruth<mailto:chandlerc at gmail.com>
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets
Ok, if no objections, I’ll add “HasVectorUAMem” feature to all AVX processors.
I’ll allow to fold an unaligned load to instruction.
- Elena
From: Das, Dibyendu [mailto:Dibyendu.Das at amd.com]
Sent: Monday, December 15, 2014 07:01
To: Chandler Carruth; Demikhovsky, Elena
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [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> [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<mailto: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
---------------------------------------------------------------------
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/20141215/4639d7eb/attachment.html>