| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This is the resolution we came to in D38824.
llvm-svn: 318616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some target devices (e.g. Nvidia GPUs) don't support dynamic stack
allocation and hence no VLAs. Print errors with description instead
of failing in the backend or generating code that doesn't work.
This patch handles explicit uses of VLAs (local variable in target
or declare target region) or implicitly generated (private) VLAs
for reductions on VLAs or on array sections with non-constant size.
Differential Revision: https://reviews.llvm.org/D39505
llvm-svn: 318601
|
|
|
|
|
|
| |
Added codegen support for `target simd` directive.
llvm-svn: 318536
|
|
|
|
|
|
|
|
|
| |
Since SVN r318510, the MinGW/ARM configuration defaults to
dwarf exception handling.
Differential Revision: https://reviews.llvm.org/D39533
llvm-svn: 318511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In https://reviews.llvm.org/D39572 , I added support for specifying
`Type` when invoking `InMemoryFileSystem::addFile()`.
However, I didn't account for the fact that when `Type` is
`directory_file`, we need to construct an `InMemoryDirectory`, not an
`InMemoryFile`, or else clients cannot create files inside that
directory.
This diff fixes the bug and adds a test.
Test Plan: New test added. Ran test with:
% make -j12 check-clang-tools
Reviewers: bkramer, hokein
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40140
llvm-svn: 318445
|
|
|
|
|
|
|
|
|
|
|
| |
A first step toward removing the repetition of
features/CPU info in the x86 target info, this
patch pulls all the processor information out into
its own .def file.
Differential Revision: https://reviews.llvm.org/D40093
llvm-svn: 318343
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM exposes a file in the backend (X86TargetParser.def) that
contains information about the correct list of CpuIs values.
This patch removes 2 of the copied and pasted versions of this
list from clang and instead includes the data from the .def file.
Differential Revision: https://reviews.llvm.org/D40054
llvm-svn: 318234
|
|
|
|
|
|
|
|
| |
Patch by: Andras Leitereg!
Differential Revision: https://reviews.llvm.org/D39372
llvm-svn: 318150
|
|
|
|
|
|
| |
Added codegen for `#pragma omp target parallel for simd` and clauses.
llvm-svn: 317813
|
|
|
|
|
|
|
| |
`#pragma omp target parallel for simd` mistakenly was not treated as a
simd directive, fixed this problem.
llvm-svn: 317811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This implements a FIXME in InMemoryFileSystem::addFile(), allowing
clients to specify User, Group, Type, and/or Perms when creating a
file in an in-memory filesystem.
New tests included. Ran tests with:
% ninja BasicTests && ./tools/clang/unittests/Basic/BasicTests
Fixes PR#35172 (https://bugs.llvm.org/show_bug.cgi?id=35172)
Reviewers: bkramer, hokein
Reviewed By: bkramer, hokein
Subscribers: alexfh
Differential Revision: https://reviews.llvm.org/D39572
llvm-svn: 317800
|
|
|
|
| |
llvm-svn: 317719
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: This change has a cyclical dependency on D39485. Both these changes must be submitted at the same time to avoid a build breakage.
Reviewers: vlad.tsyrklevich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39486
llvm-svn: 317616
|
|
|
|
|
|
|
|
| |
These were missed in SVN r316783, which broke compiling mingw-w64 CRT.
Differential Revision: https://reviews.llvm.org/D39631
llvm-svn: 317504
|
|
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 317381
|
|
|
|
|
|
| |
match GCC
llvm-svn: 317069
|
|
|
|
|
|
|
|
| |
The existing coverage for the Darwin targets wasn't enough to catch all
the variations. Improve the coverage a bit further and fix a few cases
for Darwin targets.
llvm-svn: 316826
|
|
|
|
|
|
|
|
|
| |
Centralise the definitions of these compiler vended types to aid
inspection to ensure that they are defined similarly. The one case that
stands out is the Darwin case where the types do not match up. This
fixes the API conformance for APCS-GNU as well.
llvm-svn: 316810
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.
This patch also sets the 'default' for this checking to
'supported', since only X86 has implemented the support
for checking valid CPU names and Feature Names.
One test was changed to i686, since it uses a lakemont,
which would otherwise be prohibited in x86_64.
Differential Revision: https://reviews.llvm.org/D39357
llvm-svn: 316783
|
|
|
|
|
|
|
|
|
| |
These are not valid values for this, and are pretty
non-sensical, since LLVM doesn't understand them.
Differential Revision: https://reviews.llvm.org/D39378
llvm-svn: 316781
|
|
|
|
|
|
| |
sse4 is valid for target attribute and functions as an alias of sse4.2.
llvm-svn: 316718
|
|
|
|
|
|
|
|
| |
I think the only reason they are different is because we don't set tune_i686 for -march=i686 to match GCC. But GCC 4.9.0 seems to have changed this behavior and they do set it now. So I think they can aliases now.
Differential Revision: https://reviews.llvm.org/D39349
llvm-svn: 316712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CUDA 9's minimum sm is sm_30.
Ideally we should also make sm_30 the default when compiling with CUDA
9, but that seems harder than it should be.
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D39109
llvm-svn: 316611
|
|
|
|
|
|
| |
As indicated by Table 1-1 in Intel Architecture Instruction Set Extensions and Future Features Programming Reference from October 2017.
llvm-svn: 316593
|
|
|
|
|
|
|
|
| |
Preparing to do a refactor of CPU/feature checking, this
patch pulls the one CPU implementation from the .h file
to the .cpp file.
llvm-svn: 316338
|
|
|
|
|
|
|
|
|
| |
NetBSD uses `long int` for `intptr_t` on ARM. This was changed in SVN
r316046, referenced against other compilers. However, NetBSD's
reference was incorrect as the current clang behaviour is more
up-to-date. Restore the original behaviour for that target.
llvm-svn: 316204
|
|
|
|
|
|
|
| |
Improve amdgcn macro test
Differential Revision: https://reviews.llvm.org/D38667
llvm-svn: 316181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"
The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The
-mhvx flag adds the target-feature "+hvxv{hvx_version}"
The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.
The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"
The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag
The macro HVX_LENGTH is defined and is set to the length of the vector.
Eg: #define HVX_LENGTH 64
The macro HVX_ARCH is defined and is set to the version of the HVX.
Eg: #define HVX_ARCH 62
Differential Revision: https://reviews.llvm.org/D38852
llvm-svn: 316102
|
|
|
|
|
|
|
|
|
|
| |
Darwin and OpenBSD are the only platforms which use `long int` for
`__INTPTR_TYPE__`. The other platforms use `int` in 32-bit, and `long
int` on 64-bit (except for VMS and Windows which are LLP64). Adjust the
type definitions to match the platform definitions. We now generate the
same definition as GCC on all the targets.
llvm-svn: 316046
|
|
|
|
|
|
|
| |
The `IntPtrType` for Windows ARM should be `int` as per MSVC. Adjust
the type accordingly.
llvm-svn: 316042
|
|
|
|
|
|
|
|
| |
This allows to return the static value that we know at compile time.
Differential Revision: https://reviews.llvm.org/D38968
llvm-svn: 316001
|
|
|
|
|
|
|
|
|
| |
This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.
Differential Revision: https://reviews.llvm.org/D38772
llvm-svn: 315924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
|
|
|
|
|
|
|
|
| |
This adds support Knights Mill CPU. Preprocessor defines match gcc's implementation.
Differential Revision: https://reviews.llvm.org/D38813
llvm-svn: 315723
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38821
llvm-svn: 315567
|
|
|
|
|
|
| |
The compiler-rt implementation already supported it, it just wasn't exposed.
llvm-svn: 315517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FindFirstFileEx/FindNextFile results on Windows.
This allows clients to avoid an unnecessary fs::status() call on each
directory entry. Because the information returned by FindFirstFileEx
is a subset of the information returned by a regular status() call,
I needed to extract a base class from file_status that contains only
that information.
On my machine, this reduces the time required to enumerate a ThinLTO
cache directory containing 520k files from almost 4 minutes to less
than 2 seconds.
Differential Revision: https://reviews.llvm.org/D38716
llvm-svn: 315378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D38371
This patch implements codegen for the combined 'teams distribute" OpenMP pragma and adds regression tests for all its clauses.
llvm-svn: 314905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also:
- Add support for some older Myriad CPUs that were missing.
- Fix some incorrect compiler defines for exisitng CPUs.
Reviewers: jyknight
Subscribers: fedor.sergeev
Differential Revision: https://reviews.llvm.org/D37551
llvm-svn: 314706
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently AMDGPU inline asm only allow v and s as register names in constraints.
This patch allows the following register names in constraints: (n, m is unsigned integer, n < m)
v
s
{vn} or {v[n]}
{sn} or {s[n]}
{S} , where S is a special register name
{v[n:m]}
{s[n:m]}
Differential Revision: https://reviews.llvm.org/D37568
llvm-svn: 314452
|
|
|
|
| |
llvm-svn: 314367
|
|
|
|
|
|
| |
The data layout was changed in r314179 to fix atomic loads and stores.
llvm-svn: 314354
|
|
|
|
|
|
|
| |
Add support for the `preserve_mostcc` and `preserve_allcc` on Windows
x86_64 and AArch64. This is used by Swift.
llvm-svn: 314236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
|
|
|
|
|
| |
Change-Id: I6c22478d16b8e02ce60dae2f8c80d43bc5ab3a9c
llvm-svn: 314104
|
|
|
|
|
|
|
|
|
|
|
| |
This is to fix PR31620. MaxAtomicInlineWidth is set to 128 for x86_64. However
for target without cx16 support, 128 atomic operation will generate __sync_*
libcalls. The patch set MaxAtomicInlineWidth to 64 if the target doesn't support
cx16.
Differential Revision: https://reviews.llvm.org/D38046
llvm-svn: 313992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a class that can help to build tools that require cross
translation unit facilities. This class allows function definitions to be loaded
from external AST files based on an index. In order to use this functionality an
index is required. The index format is a flat text file but it might be
replaced with a different solution in the near future. USRs are used as names to
look up the functions definitions. This class also does caching to avoid
redundant loading of AST files.
Right now only function defnitions can be loaded using this API because this is
what the in progress cross translation unit feature of the Static Analyzer
requires. In to future this might be extended to classes, types etc.
Differential Revision: https://reviews.llvm.org/D34512
llvm-svn: 313975
|
|
|
|
|
|
|
|
| |
This arranges more of the Intel and AMD CPUs into fallthrough positions based on their features. We may be able to merge this new AMD set with the BTVER or BDVER sets but I didn't look that closely.
Differential Revision: https://reviews.llvm.org/D37941
llvm-svn: 313497
|