| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Patch allows to recognize additional registers x8d, x8b, x8w - x15d, x15b, x15w in inline assembler, already recognized by backend
Differential Revision: http://reviews.llvm.org/D12594
llvm-svn: 246835
|
|
|
|
|
|
|
|
|
|
| |
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
|
|
|
|
|
|
|
|
|
| |
targets.
Differential Revision: http://reviews.llvm.org/D12244
Change-Id: Iffd4e822c15e18668fe8868278230ff232ef50aa
llvm-svn: 246768
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
|
|
|
|
| |
llvm-svn: 246467
|
|
|
|
|
|
|
|
| |
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
llvm-svn: 246375
|
|
|
|
|
|
| |
namespace.
llvm-svn: 246368
|
|
|
|
| |
llvm-svn: 246346
|
|
|
|
| |
llvm-svn: 246260
|
|
|
|
|
|
| |
and replace all callers.
llvm-svn: 246259
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ABI string only exists to communicate with TargetCodeGenInfo.
Concretely, since we only used "avx*" ABI strings on x86_64 (as AVX
doesn't affect the i386 ABIs), this meant that, when initializing
SimdDefaultAlign, we would ignore AVX/AVX512 on i386, for no good
reason.
Instead, directly check the features. A similar change for
MaxVectorAlign will follow.
Differential Revision: http://reviews.llvm.org/D12390
llvm-svn: 246228
|
|
|
|
| |
llvm-svn: 246202
|
|
|
|
| |
llvm-svn: 246180
|
|
|
|
|
|
|
|
|
| |
with multiple uses of feature map construction.
Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.
llvm-svn: 246128
|
|
|
|
| |
llvm-svn: 246127
|
|
|
|
|
|
| |
this is going to see use shortly in unifying feature set construction.
llvm-svn: 246122
|
|
|
|
| |
llvm-svn: 246027
|
|
|
|
| |
llvm-svn: 246020
|
|
|
|
| |
llvm-svn: 246006
|
|
|
|
|
|
|
|
|
| |
This involved specializing handleUserFeatures so that we could perform
diagnostics on -only- user supplied features and migrating the rest of
the initialization functions to set features based on enabling and disabling
full feature sets. No functional change intended.
llvm-svn: 245936
|
|
|
|
|
|
| |
specialize it on the targets.
llvm-svn: 245935
|
|
|
|
|
|
| |
that we're looking for conflicting options and give an explanation.
llvm-svn: 245914
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 defines that the predefined macro
__ARM_FP16_ARGS should be defined if __fp16 can be used as an argument and
result.
The support for __fp16 to be used as an argument and result is already
implemented for AArch64 so this change is just adding the missing macro.
Differential Revision: http://reviews.llvm.org/D12240
llvm-svn: 245833
|
|
|
|
|
|
| |
it as they are already set correctly by X86_64TargetInfo and X86TargetInfo.
llvm-svn: 245620
|
|
|
|
| |
llvm-svn: 245618
|
|
|
|
|
|
|
| |
See
https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/i386-and-x86-64-Options.html
llvm-svn: 245459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"generic" cpu was wrongly handled as exact real CPU name of ARMv8.1A architecture.
This has been fixed, now it is abstract name, suitable for any arch.
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11640
llvm-svn: 245445
|
|
|
|
|
|
| |
with the current behavior as the name seems to match what's going on.
llvm-svn: 245405
|
|
|
|
|
|
| |
the default behavior.
llvm-svn: 245251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
long double on x86 mingw is 80bits and is aligned to 16bytes
Fixes:
https://llvm.org/bugs/show_bug.cgi?id=24398
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12037
llvm-svn: 245084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSDN says that fastcall, stdcall, thiscall, and vectorcall are all
accepted but ignored on ARM and X64.
https://msdn.microsoft.com/en-us/library/984x0h58.aspx
MSDN also says cdecl is also accepted and typically ignored
This patch brings ARM in line with how we ignore them for X64
Reviewers: rnk
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D12034
llvm-svn: 245076
|
|
|
|
| |
llvm-svn: 244962
|
|
|
|
| |
llvm-svn: 244961
|
|
|
|
| |
llvm-svn: 244749
|
|
|
|
|
|
|
|
|
| |
Let NaClMips32ELTargetInfo inherit arch values for maximum width lock-free
atomic operations.
Differential Revision: http://reviews.llvm.org/D11949
llvm-svn: 244675
|
|
|
|
| |
llvm-svn: 244346
|
|
|
|
|
|
|
|
| |
initialized. Silences -Wmissing-field-initializers.
While there convert 0 in the BUILTIN macros to nullptr.
llvm-svn: 244307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and add aarch32 to specifically refer to the 32-bit ones.
Previously, 'arm' meant only 32-bit architectures and there was no way
for a module to build with both 32 and 64 bit ARM architectures.
Now a module that is intended to work on both architectures can specify
requires arm
whereas a module only for 32-bit platforms can say
requires aarch32
and just like before, 64-bit only can say
requires aarch64
llvm-svn: 244306
|
|
|
|
|
|
|
|
| |
so that we can populate it on a per-target basis with required features.
Future commits will start using this information for warnings.
llvm-svn: 244286
|
|
|
|
|
|
| |
use of the string.
llvm-svn: 244178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
supported on AArch64.
llvm-svn: 243417
|
|
|
|
|
|
| |
We used to define them to 1, we should have defined them to 100.
llvm-svn: 243255
|
|
|
|
|
|
|
|
|
|
| |
These changes are for Android x86_64 targets to be compatible with current Android g++.
https://llvm.org/bugs/show_bug.cgi?id=23897
Use 'g' and 'Cg' for "long double" and "long double _Complex" mangled type names.
Differential Revision: http://reviews.llvm.org/D11466
llvm-svn: 243133
|
|
|
|
| |
llvm-svn: 243125
|
|
|
|
|
|
|
| |
Instead of using CPlusPlus, use Bool. No functionality change is
intended, it just makes things a tad bit more clear.
llvm-svn: 242957
|