libunwind is known to work on FreeBSD i386, amd64 (x86_64) and arm64.
It is the unwinder provided by the base system on all of those
architectures.
While here sort the OS list.
Differential Revision: https://reviews.llvm.org/D38900
llvm-svn: 315814
- Do not allow amd_amdgpu_isa directives on non-amdgcn architectures
- Do not allow amd_amdgpu_hsa_metadata on non-amdhsa OSes
- Do not allow amd_amdgpu_pal_metadata on non-amdpal OSes
Differential Revision: https://reviews.llvm.org/D38750
llvm-svn: 315812
- Emit NT_AMD_AMDGPU_ISA
- Add assembler parsing for isa version directive
- If isa version directive does not match command line arguments, then return error
Differential Revision: https://reviews.llvm.org/D38748
llvm-svn: 315808
If we are applying a byte mask to a value extracted from a shuffle, see if we can combine the mask into shuffle.
Fixes the last issue with PR22415
llvm-svn: 315807
In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.
The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.
This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.
Differential Revision: https://reviews.llvm.org/D38134
llvm-svn: 315804
We don't need a bitconvert as a root pattern in these cases. The types in the other parts of the pattern are sufficient to express the behavior of these instructions.
llvm-svn: 315798
I believe these were added incorrectly under the belief that the load size was smaller than the input register size, but that's not true.
llvm-svn: 315795
"No such file or directory: C:\\...\\tests\\Output\\shared-output.py.tmp/Output/Shared/SHARED.tmp"
And yet other forward-slashes don't seem to be causing the same
problem. I'll see if I can get ahold of a Windows machine to poke at
this directly later.
llvm-svn: 315792
Currently llvm assembler emits parsing error for valid IR assembly
alloca i32, i32 9, addrspace(5)
when alloca addr space is 5.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D38713
llvm-svn: 315791
Summary:
This patch removes the `verifyNCD` check.
The reason for this is that the other checks are sufficient to prove or disprove correctness of any DominatorTree, and that `verifyNCD` doesn't provide (in my option) better error messages then the other ones.
Additionally, this should give a (small) improvement to the total verification time, as the check is O(n), and checking the sibling property takes O(n^3).
Reviewers: dberlin, grosser, davide, brzycki
Reviewed By: brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38802
llvm-svn: 315790
There were two copies of the logic needed to construct a line stats
object for each line in a range: this patch brings it down to one. In
the future, this will make it easier for IDE clients to display coverage
in-line in source editors. To do that, we just need to move the new
LineCoverageIterator class to libCoverage.
llvm-svn: 315789
If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.
Differential Revision: https://reviews.llvm.org/D38678
llvm-svn: 315787
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Testing: check-clang, check-ubsan
Differential Revision: https://reviews.llvm.org/D38913
llvm-svn: 315786
We use to resort on the generic implementation to get the mappings for
COPYs. The generic implementation resorts on table lookup and
dynamically allocated objects to get the valid mappings.
Given we already know how to map G_BITCAST and have the static mappings
for them, use that code path for COPY as well. This is much more
efficient.
Improve the compile time of RegBankSelect by up to 20%.
Note: When we eventually generate all the mappings via TableGen, we
wouldn't have to do that dance to shave compile time. The intent of this
change was to make sure that moving to static structure really pays off.
NFC.
llvm-svn: 315781
Summary:
Operand variable lookups are now performed by the RuleMatcher rather than
searching the whole matcher hierarchy for a match. This revealed a wrong-code
bug that currently affects ARM and X86 where patterns that use a variable more
than once in the match pattern will be imported but won't check that the
operands are identical. This can cause the tablegen-erated matcher to
accept matches that should be rejected.
Depends on D36569
Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar
Subscribers: aemerson, igorb, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D36618
llvm-svn: 315780
It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.
Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.
llvm-svn: 315772
When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true,
all of projects in compiler-rt are built with a freshly-built compiler using
a recursive CMake invocation.
(e.g. that's how compiler-rt is used in Swift)
Just now I have noticed that libFuzzer binaries were missing in such a case,
and ninja fuzzer returned "no such target", while ninja asan worked just fine.
To my surprise, the list of allowed targets was actually hardcoded in Clang!
While the current setup is clearly suboptimal, for the lack of a better fix
I'm just adding `fuzzer` to a list of `compiler-rt` targets.
Differential Revision: https://reviews.llvm.org/D38904
llvm-svn: 315771
This is particularly important for AVX512VL where we are better able to recognize the VBROADCAST loads to fold with other operations.
For AVX512VL we now use X86ISD::VBROADCAST for all of the patterns and remove the 128-bit X86ISD::VMOVDDUP.
We may be able to use this for AVX1 as well which would allow us to remove more isel patterns.
I also had to add X86ISD::VBROADCAST as a node to call combineShuffle for so that we treat it similar to X86ISD::MOVDDUP.
Differential Revision: https://reviews.llvm.org/D38836
llvm-svn: 315768
Simon Pilgrim