We might have instructions such as ext(copy(trunc)), and while cleaning
up legalization artifacts, we can also dce the copies that are in
between legalization artifacts.
llvm-svn: 318501
TransferDbgValues (capital 'T') is wired into ReplaceAllUsesWith, and
transferDbgValues (lowercase 't') is used elsewhere (e.g in Legalize).
Both functions should be doing the exact same thing. This patch
consolidates the logic into one place.
This was reverted in r318455 because some newly introduced asserts,
which I thought were NFC, were firing. I filed PR35338. For now I've
weakened the asserts.
Testing: check-llvm, check-clang, and a stage2 Rel+Deb build of clang
Differential Revision: https://reviews.llvm.org/D40104
llvm-svn: 318498
Summary:
__builtin_nexttoward lowers to a libcall, e.g. nexttowardf(), that CUDA
does not have.
Rather than try to implement it, we simply remove these functions --
nvcc doesn't support them either, and nextafter, which does work, does
essentially the same thing on GPUs, because GPUs don't have long double.
Reviewers: tra
Subscribers: cfe-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D40152
llvm-svn: 318494
Add additional RUN clauses to test for -asan-mapping-scale=5 in
selective tests, with special CHECK statements where needed.
Differential Revision: https://reviews.llvm.org/D39775
llvm-svn: 318493
All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
It turns out this #include isn't used from Host.h anyway,
but by having it it causes circular include dependencies.
This issues only surfaced while I was working on a separate
patch, so I'm submitting this first so that it's independent
of the other, unrelated patch.
llvm-svn: 318489
This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.
You can observe this by running:
ninja -nv check-all | grep debuginfo-tests
And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice. The fix is
going to involve either:
a) figuring out that we're running in this "deprecated" configuration,
and then deleting the clang/test/debuginfo-tests path, which should
cause it to behave identically to before, or:
b) make lit smart enough that it doesn't descend into a sub-suite if
that sub-suite already has a lit.cfg file.
llvm-svn: 318486
iterator to walk the list which keeps changing inside the loop. When the
UseList contains several uses with the same user, we end processing the same
user more than once, which leads to an assert.
With this fix, unique users are saved and processed later to avoid
processing duplicates.
Differential Revision: https://reviews.llvm.org/D39864
llvm-svn: 318477
explicitly instantiated, still emit it with each use.
We don't emit a definition of the member with an explicit instantiation
definition (and indeed it appears that we're not allowed to, since an explicit
instantiation definition does not constitute an odr-use and only odr-use
permits definition for defaulted special members). So we still need to emit a
weak definition with each use.
This also makes defaulted-in-class declarations behave more like
implicitly-declared special members, which matches their design intent.
And it matches the way this problem was solved in GCC.
llvm-svn: 318474
't' constraint normally only accepts f32 operands, but for VCVT the
operands can be i32. LLVM is overly restrictive and rejects asm like:
float foo() {
float result;
__asm__ __volatile__(
"vcvt.f32.s32 %[result], %[arg1]\n"
: [result]"=t"(result)
: [arg1]"t"(0x01020304) );
return result;
}
Relax the value type for 't' constraint to either f32 or i32.
Differential Revision: https://reviews.llvm.org/D40137
llvm-svn: 318472
The tests are ported as follows:
contiguous_container_crash.cc
use-after-delete.cc
use-after-free.cc
Replace hardwired shadow granularity in CHECK statements with regex.
max_redzone.cc
Bump max_redzone parameter to 32.
memset_test.cc
Bump size parameter of __asan_poison_memory_region to 32.
scariness_score_test.cc
For "far-from-bounds" heap overflow, make sure overflow is more than
one shadow granularity away.
At large shadow granularity, there is not enough redzone between
stack elements to detect far-from-bounds, so fake out that test.
Differential Revision: https://reviews.llvm.org/D39773
llvm-svn: 318470
Only do this pre-legalize in case we're using the sign extend to legalize for KNL.
This recovers all of the tests that changed when I stopped SelectionDAGBuilder from deleting sign extends.
There's more work that could be done here particularly to fix the i8->i64 test case that experienced split.
llvm-svn: 318468
Previously SelectionDAGBuilder would remove this sign extend leading to a failure during isel.
The codegen here isn't very nice as we ended up triggering a split.
llvm-svn: 318467
The sign extend might be from an i16 or i8 type and was inserted by InstCombine to match the pointer width. X86 gather legalization isn't currently detecting this to reinsert a sign extend to make things legal.
It's a bit weird for the SelectionDAGBuilder to do this kind of optimization in the first place. With this removed we can at least lean on InstCombine somewhat to ensure the index is i32 or i64.
I'll work on trying to recover some of the test cases by removing sign extends in the backend when its safe to do so with an understanding of the current legalizer capabilities.
This should fix PR30690.
llvm-svn: 318466
Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocateMappedMemory method is updated to request full permissions for memory
blocks so that they can be marked executable later.
llvm-svn: 318464
Rather than assertion failing, we can fall back to the
non-optimized version which works for any shadow scale.
Differential Revision: https://reviews.llvm.org/D39474
llvm-svn: 318460
Passing lists to functions in CMake is tricky, any list argument
has to be quoted otherwise it'll be expanded. To avoid this issue,
use cmake_parse_arguments in runtime functions and pass lists using
a keyword argument which eliminates any ambiguity when dealing with
lists.
Differential Revision: https://reviews.llvm.org/D40087
llvm-svn: 318457
The wider element type will normally cause legalize to try to split and scalarize the gather/scatter, but we can't handle that. Instead, truncate the index early so the gather/scatter node is insulated from the legalization.
This really shouldn't happen in practice since InstCombine will normalize index types to the same size as pointers.
llvm-svn: 318452
TransferDbgValues (capital 'T') is wired into ReplaceAllUsesWith, and
transferDbgValues (lowercase 't') is used elsewhere (e.g in Legalize).
Both functions should be doing the exact same thing. This patch
consolidates the logic into one place.
Differential Revision: https://reviews.llvm.org/D40104
llvm-svn: 318448
If the linker chose to store the full section name instead of truncating
it, this field doesn't contain a truncated name, but an offset into
the string table of the binary. The string table isn't loaded/mapped
into memory during runtime though, so it's not possible to read the
full section name, unless we try to locate the DLL/EXE on disk that
the HMODULE corresponds to and load that manually.
Due to this, lld now always prefers writing a truncated section name
for sections that will be mapped at runtime, even when debug info is
enabled.
Differential Revision: https://reviews.llvm.org/D39918
llvm-svn: 318446
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
Vedant Kumar