Commit Graph

6 Commits

Author SHA1 Message Date
Simon Moll 0aab344104 [Clang] Allow "ext_vector_type" applied to Booleans
This is the `ext_vector_type` alternative to D81083.

This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vector_type) in C/C++.

This is intended as the canonical type for SIMD masks and facilitates
clean vector intrinsic declarations.  Vectors of i1 are supported on IR
level and below down to many SIMD ISAs, such as AVX512, ARM SVE (fixed
vector length) and the VE target (NEC SX-Aurora TSUBASA).

The RFC on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D88905
2022-03-16 11:10:32 +01:00
Reid Kleckner 89fbd55145 Revert r333791 "Cap "voluntary" vector alignment at 16 for all Darwin platforms."
Adding __attribute__((aligned(32))) to __m256 breaks the implementation
of _mm256_loadu_ps on Windows. On Windows, alignment attributes have
higher precedence than packing attributes.

We also might want to carefully consider the consequences of changing
our vector typedefs, since many users copy them and invent their own
new, non-Intel specific vector type names.

llvm-svn: 333958
2018-06-04 21:39:20 +00:00
John McCall 280c656031 Cap "voluntary" vector alignment at 16 for all Darwin platforms.
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
  Intel, so we did not have a consistent ABI.

This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).

Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects.  The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.

llvm-svn: 333791
2018-06-01 21:34:26 +00:00
Ahmed Bougacha 02b7b56af8 [X86] Bump Darwin MaxVectorAlign to 64 when AVX512 is enabled.
Without this, 64-byte vector types (__m512), specified to be 64-byte
aligned in the AVX512 draft SysV ABI, will only be 32-byte aligned.

This is analoguous to AVX, for which we accept 32-byte max alignment.

Differential Revision: http://reviews.llvm.org/D10724

llvm-svn: 246230
2015-08-27 22:42:12 +00:00
Ahmed Bougacha 82b619ea68 [X86] Conditionalize Darwin MaxVectorAlign on the presence of AVX.
There's no point in using a larger alignment if we have no instructions
that would benefit from it.

Differential Revision: http://reviews.llvm.org/D12389

llvm-svn: 246229
2015-08-27 22:30:38 +00:00
Chad Rosier cc40ea7f9a Add a per target max vector alignment field (e.g., 32-byte alignment for x86 due to
AVX).  Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size.  Thus, very large vectors will be over-aligned with no 
benefit.  Target owners should set this target max.

llvm-svn: 160209
2012-07-13 23:57:43 +00:00