9 Commits

Author SHA1 Message Date
Ulrich Weigand
8424bf207e [SystemZ] Add support for new cpu architecture - arch15
This patch adds support for the next-generation arch15
CPU architecture to the SystemZ backend.

This includes:
- Basic support for the new processor and its features.
- Detection of arch15 as host processor.
- Assembler/disassembler support for new instructions.
- Exploitation of new instructions for code generation.
- New vector (signed|unsigned|bool) __int128 data types.
- New LLVM intrinsics for certain new instructions.
- Support for low-level builtins mapped to new LLVM intrinsics.
- New high-level intrinsics in vecintrin.h.
- Indicate support by defining  __VEC__ == 10305.

Note: No currently available Z system supports the arch15
architecture.  Once new systems become available, the
official system name will be added as supported -march name.
2025-01-20 19:30:21 +01:00
Ulrich Weigand
f73e87f53f
[Clang][Sema] Do not accept "vector _Complex" for AltiVec/ZVector (#90467)
The AltiVec (POWER) and ZVector (IBM Z) language extensions do not
support using the "vector" keyword when the element type is a complex
type, but current code does not verify this.

Add a Sema check and diagnostic for this case.

Fixes: https://github.com/llvm/llvm-project/issues/88399
2024-04-30 11:34:34 +02:00
Richard Smith
c624510f13 For PR17164: split -fno-lax-vector-conversion into three different
levels:

 -- none: no lax vector conversions [new GCC default]
 -- integer: only conversions between integer vectors [old GCC default]
 -- all: all conversions between same-size vectors [Clang default]

For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)

Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.

This reinstates r371805, reverted in r371813, with an additional fix for
lldb.

llvm-svn: 371817
2019-09-13 06:02:15 +00:00
Jonas Devlieghere
4aaa77e48d Revert "For PR17164: split -fno-lax-vector-conversion into three different"
This breaks the LLDB build. I tried reaching out to Richard, but haven't
gotten a reply yet.

llvm-svn: 371813
2019-09-13 05:16:59 +00:00
Richard Smith
49c4e58b75 For PR17164: split -fno-lax-vector-conversion into three different
levels:

 -- none: no lax vector conversions [new GCC default]
 -- integer: only conversions between integer vectors [old GCC default]
 -- all: all conversions between same-size vectors [Clang default]

For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)

Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.

llvm-svn: 371805
2019-09-13 02:20:00 +00:00
Ulrich Weigand
2927071750 [SystemZ] Actually enable -mzvector keywords
It appears when initially committing the support for the IBM Z vector
extension language, one critical line was lost, causing the specific
keywords __vector, __bool, and vec_step to not actually be enabled.
(Note that this does not affect "vector" and "bool"!)

Unfortunately, this was not caught by any tests either.  (All existing
Z vector tests just use the regular "vector" and "bool" keywords ...)

Fixed by adding the missing line and updating the tests.

llvm-svn: 344611
2018-10-16 14:57:20 +00:00
Simon Dardis
7cd5876e60 [Sema] Support implicit scalar to vector conversions
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.

If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.

Contributions from: Petar Jovanovic

Reviewers: bruno, vkalintiris

Differential Revision: https://reviews.llvm.org/D25866

llvm-svn: 302935
2017-05-12 19:11:06 +00:00
Davide Italiano
32cbff7809 [Sema] Be consistent about diagnostic wording: always use "cannot".
Discussed with Richard Smith.

llvm-svn: 245162
2015-08-15 15:23:14 +00:00
Ulrich Weigand
3c5038a535 Add support for System z vector language extensions
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX.  The main differences are:

- vector long, vector float and vector pixel are not supported

- vector long long and vector double are supported (like VSX)

- comparison operators return a vector rather than a scalar integer

- shift operators behave like the OpenCL shift operators

- vector bool is only supported as argument to certain operators;
  some operators allow mixing a bool with a non-bool vector 

This patch adds clang support for the extension.  It is closely modelled
on the AltiVec support.  Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC).  There's also a separate LangOpt.

The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.

Based on a patch by Richard Sandiford.

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

llvm-svn: 243642
2015-07-30 14:08:36 +00:00