Using RAUW was wrong here; if we have a switch transform such as:
18 -> 6 then
6 -> 0
If we use RAUW, while performing the second transform the *transformed* 6
from the first will be also replaced, so we end up with:
18 -> 0
6 -> 0
Found by clang stage2 bootstrap; testcase added.
llvm-svn: 277332
The branch relaxation pass is computing the wrong offsets because it assumes
TLSDESC_CALLSEQ eats up 4 bytes, when in fact it is lowered to an instruction
sequence taking up 16 bytes. This can become a problem in huge files with lots
of TLS accesses, as it may slowly move branch targets out of the range computed
by the branch relaxation pass.
Fixes PR24234 https://llvm.org/bugs/show_bug.cgi?id=24234
Differential Revision: https://reviews.llvm.org/D22870
llvm-svn: 277331
It looks like the two independent parts of the rotate operation (a lshr and shl) are being reordered on some bots. Add CHECK-DAGs to account for this.
llvm-svn: 277329
Summary:
This patch adds an option //--show-description// to add the defect description to the list of defect. This helps to get a better understanding of the defect without opening the page.
For example, this is used for Firefox:
https://people.mozilla.org/~sledru/reports/fx-scan-build/
Reviewers: rizsotto.mailinglist, zaks.anna
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22810
llvm-svn: 277328
If a switch is sparse and all the cases (once sorted) are in arithmetic progression, we can extract the common factor out of the switch and create a dense switch. For example:
switch (i) {
case 5: ...
case 9: ...
case 13: ...
case 17: ...
}
can become:
if ( (i - 5) % 4 ) goto default;
switch ((i - 5) / 4) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
}
or even better:
switch ( ROTR(i - 5, 2) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
}
The division and remainder operations could be costly so we only do this if the factor is a power of two, and emit a right-rotate instead of a divide/remainder sequence. Dense switches can be lowered significantly better than sparse switches and can even be transformed into lookup tables.
llvm-svn: 277325
When we run halt_on_error-torture.cc with 10 threads and 20 iterations with halt_on_error=false:suppress_equal_pcs=false, we write 200 reports to 10.txt file and sometimes have collisions.
We have CHECK-COLLISION check that greps 'AddressSanitizer: nested bug in the same thread, aborting' message in 10.txt, but it doesn't contain this line.
If I don't redirect stderr > 10.txt 'AddressSanitizer: nested bug in the same thread, aborting' is printed to my screen as expected.
Same happens for halt_on_error_suppress_equal_pcs.cc and halt_on_error-torture.cc. This happens because of kernel bug: https://lkml.org/lkml/2014/2/17/324
Furtunately, we can fix these tests by implicitly setting O_APPEND for opened files (use >> instead of > for stderr redirection).
Differential Revision: https://reviews.llvm.org/D22921
llvm-svn: 277324
Initialize all AArch64-specific passes in the TargetMachine so they can be run
by llc. This can lead to conflicts in opt with some command line options that
share the same name as the pass, so I took this opportunity to do some cleanups:
* rename all relevant command line options from "aarch64-blah" to
"aarch64-enable-blah" and update the tests accordingly
* run clang-format on their declarations
* move all these declarations to a common place (the TargetMachine) as opposed
to having them scattered around (AArch64BranchRelaxation and
AArch64AddressTypePromotion were the only offenders)
llvm-svn: 277322
When extracting a set of blocks make sure to inherit all of the target
dependent attributes to make sure that the function will be valid for
lowering. One example is the "target-features" attribute for x86, if the
extracted region has functionality that relies on a specific feature it
will fail to be lowered.
This also allows for extracted functions to be valid for inlining, at
least back into the parent function, as the target attributes are tested
when inlining for compatibility.
Patch by River Riddle!
Differential Revision: https://reviews.llvm.org/D22713
llvm-svn: 277315
Added ability to estimate the entry count of the extracted function and
the branch probabilities of the exit branches.
Patch by River Riddle!
Differential Revision: https://reviews.llvm.org/D22744
llvm-svn: 277313
Summary:
Some cpuid bit defines are named slightly different from how gcc's
cpuid.h calls them.
Define a few more compatibility names to appease software built for gcc:
* `bit_PCLMUL` alias of `bit_PCLMULQDQ`
* `bit_SSE4_1` alias of `bit_SSE41`
* `bit_SSE4_2` alias of `bit_SSE42`
* `bit_AES` alias of `bit_AESNI`
* `bit_CMPXCHG8B` alias of `bit_CX8`
While here, add the misssing 29th bit, `bit_F16C` (which is how gcc
calls this bit).
Reviewers: joerg, rsmith
Subscribers: bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D22010
llvm-svn: 277307
As discussed on PR14593, this patch adds support for lowering to SHLD/SHRD from the patterns generated by DAGTypeLegalizer::ExpandShiftWithKnownAmountBit.
Differential Revision: https://reviews.llvm.org/D23000
llvm-svn: 277299
Summary:
Due to a QoI issuse in FreeBSD's libcxxrt-based demangler, one sanitizer
symbolizer test consistently appears to fail:
Value of: DemangleSwiftAndCXX("foo")
Actual: "float"
Expected: "foo"
This is because libcxxrt's __cxa_demangle() incorrectly demangles the "foo"
identifier to "float". It should return an error instead.
For now, XFAIL this particular test for FreeBSD, until we can fix libcxxrt
properly (which might take some time to coordinate with upstream).
Reviewers: rnk, zaks.anna, emaste
Subscribers: emaste, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23001
llvm-svn: 277297
We had import_directory_table_entry and
coff_import_directory_table_entry, remove one. Also, factor out the
logic which determins if a descriptor is a terminator.
llvm-svn: 277296
Summary:
On windows, an export can be redirected to an other DLL.
This patch is adding the required support to the internal
GetProcAddress implementation.
This case was encountered by instrumenting chromium (win 64-bits)
using this GN configuration:
```
is_component_build = true
is_debug = false
enable_nacl = false
is_clang = true
is_asan = true
clang_base_path = "d:\src\llvm\ninja64"
clang_use_chrome_plugins = false
clang_version = "4.0.0"
```
The operating system is win7 (x64).
Visual Studio: 2015 Professional
Reviewers: rnk
Subscribers: llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D22880
llvm-svn: 277294
Removed AssertZext node, which was inserted between X86ISD::SETCC and "truncate to i1".
Differential Revision: https://reviews.llvm.org/D22850
llvm-svn: 277289
are very handy when parsing text.
They are essentially a combination of startswith and a self-modifying
drop_front, or endswith and drop_back respectively.
Differential Revision: https://reviews.llvm.org/D22723
llvm-svn: 277288
James Molloy