The pass walk through the machine function and assign the register banks
using the default mapping. In other words, there is no attempt to reduce
cross register copies.
llvm-svn: 265707
Summary:
The strlen interceptor is sometimes invoked too early for REAL(strlen) to
be initialized. A special check is added to use internal_strlen for this
situation.
Reviewers: dim
Subscribers: llvm-commits, samsonov
Differential Revision: http://reviews.llvm.org/D18851
Change-Id: I3acc58f4abbae1904f25324abd84efea67aad0a2
llvm-svn: 265705
the mapping of an instruction on register bank.
For most instructions, it is possible to guess the mapping of the
instruciton by using the encoding constraints.
It remains instructions without encoding constraints.
For copy-like instructions, we try to propagate the information we get
from the other operands. Otherwise, the target has to give this
information.
llvm-svn: 265703
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.
llvm-svn: 265702
helper class.
The default constructor creates invalid (isValid() == false) instances
and may be used to communicate that a mapping was not found.
llvm-svn: 265699
A virtual register may have either a register bank or a register class.
This is represented by a PointerUnion between the related classes.
Typically, a virtual register went through the following states
regarding register class and register bank:
1. Creation: None is set. Virtual registers are fully generic.
2. Register bank assignment: Register bank is set. Virtual registers
live into a register bank, but we do not know the constraints they need
to fulfil.
3. Instruction selection: Register class is set. Virtual registers are
bound by encoding constraints.
To map these states to GlobalISel, the IRTranslator implements #1,
RegBankSelect #2, and Select #3.
llvm-svn: 265696
A draft line added to release notes for PPC, to keep a record of changes.
This is just a draft and will be rewritten towards the end of release.
llvm-svn: 265694
Summary:
This patch adds the support for detecting suspicious string
literals and their //incorrect// usage.
The following example shows a incorrect character escaping leading
to an embedded NUL character.
```
std::string str = "\0x42"; // Should be "\x42".
```
The patch also add detection of truncated literal when a literal
is passed to a string constructor.
Reviewers: hokein, alexfh
Subscribers: LegalizeAdulthood, bcraig, Eugene.Zelenko, bkramer, cfe-commits
Differential Revision: http://reviews.llvm.org/D18783
llvm-svn: 265691
Return is now considered a predicable instruction, and is converted
to a newly-added CondReturn (which maps to BCR to %r14) instruction by
the if conversion pass.
Also, fused compare-and-branch transform knows about conditional
returns, emitting the proper fused instructions for them.
This transform triggers on a *lot* of tests, hence the huge diffstat.
The changes are mostly jX to br %r14 -> bXr %r14.
Author: koriakin
Differential Revision: http://reviews.llvm.org/D17339
llvm-svn: 265689
As suggested by Chandler in his review comments for D18662, this
follow-on patch renames some variables in GetLoadValueForLoad and
CoerceAvailableValueToLoadType to hopefully make it more obvious
which variables hold value sizes and which hold load/store sizes.
No functional change intended.
llvm-svn: 265687
Follow-up to D18775 and related clang change. AtomicOrdering is a lattice, 'stronger' is the right thing to do, direct comparison is fraught with peril.
llvm-svn: 265685
When GVN wants to re-interpret an already available value in a smaller
type, it needs to right-shift the value on big-endian systems to ensure
the correct bytes are accessed. The shift value is the difference of
the sizes of the two types.
This is correct as long as both types occupy multiples of full bytes.
However, when one of them is a sub-byte type like i1, this no longer
holds true: we still need to shift, but only to access the correct
*byte*. Accessing bits within the byte requires no shift in either
endianness; e.g. an i1 resides in the least-significant bit of its
containing byte on both big- and little-endian systems.
Therefore, the appropriate shift value to be used is the difference of
the *storage* sizes of the two types. This is already handled correctly
in one place where such a shift takes place (GetStoreValueForLoad), but
is incorrect in two other places: GetLoadValueForLoad and
CoerceAvailableValueToLoadType.
This patch changes both places to use the storage size as well.
Differential Revision: http://reviews.llvm.org/D18662
llvm-svn: 265684
http://reviews.llvm.org/D18562
A large number of testcases has been modified so they pass after this test.
One testcase is deleted, because I realized even after undoing the original
change that was committed with this testcase, the testcase still passes. So
I removed it. The change to one other testcase (test/CodeGen/PowerPC/pr25802.ll)
is an arbitrary change to keep it passing. Given the original intention of the
testcase, and the fact that fixing it will require some time to change the testcase,
we concluded that this quick change will be enough.
llvm-svn: 265683
Summary:
This is the same kind of bug than [[ http://reviews.llvm.org/D18238 | D18238 ]].
Fix crashes caused by deferencing null pointer when declarations parsing may be delayed.
The body of the declarations may be null.
The crashes were observed with a Windows build of clang-tidy and the following command-line.
```
command-line switches: -fms-compatibility-version=19 -fms-compatibility
```
Reviewers: alexfh
Subscribers: kimgr, LegalizeAdulthood, cfe-commits
Differential Revision: http://reviews.llvm.org/D18852
llvm-svn: 265681
Going through a string removes some of the smarts of the diagnosic printer
and makes the code more complicated. This change has some cosmetic impact
on the output but that's mostly minor.
llvm-svn: 265680
Summary:
In Release mode, the check was infinite looping over chromium code base.
It seems there is something strange with the creation of the Maps.
I believe the compiler is making some assumption with the implicit conversion from enum <-> int.
By moving the map to a standard switch/cases, we no longer allocate memory and we can keep the same behavior. For a small amount of elements, this is fine.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18833
llvm-svn: 265679
Summary: This makes it possible to insert nops at the end of blocks.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18549
llvm-svn: 265678
isinf (is infinite) and isfinite should be implemented with the same function
except we change the comparison operator.
See PR27145 for more details:
https://llvm.org/bugs/show_bug.cgi?id=27145
Ref: forked off of the discussion in D18513.
Differential Revision: http://reviews.llvm.org/D18648
llvm-svn: 265675
This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
Summary:
Clang-tidy is reporting a warning of redundant string initialisation
on a string parameter initialized with empty string.
See bug: 27087
The reported example is:
```
#include <string>
void fn(std::string a = "");
```
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18829
llvm-svn: 265671
For VGPR_32 operand disassembler expects a VGPR register encoded as 0..255 (enum8 src operand).
readfirstlane/readline actually has enum9 operand and this change fixes VGPR_32 to VS_32 (enum9 encoding).
Differential Revision: http://reviews.llvm.org/D18696
llvm-svn: 265670
construct.
OpenMP 4.0 defines '#pragma omp declare simd' construct that may have
associated 'simdlen' clause with constant positive expression as an
argument:
simdlen(<const_expr>)
Patch adds parsin and semantic analysis for simdlen clause.
llvm-svn: 265668
This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. Patch
for Clang http://reviews.llvm.org/D15524
Differential Revision: http://reviews.llvm.org/D15525
llvm-svn: 265667
On one of our testing machines, we're running the tests under heavy load, and especially in the fork-based TSan tests, we're seeing timeouts when a test uses sleep(10), assuming that calling fork() on another thread will finish sooner than that. This patch removes a timeout and makes another one longer.
Differential Revision: http://reviews.llvm.org/D18476
llvm-svn: 265666
OS X provides atomic functions in libkern/OSAtomic.h. These provide atomic guarantees and they have alternatives which have barrier semantics. This patch adds proper TSan support for the functions from libkern/OSAtomic.h.
Differential Revision: http://reviews.llvm.org/D18500
llvm-svn: 265665
To avoid using the public header (tsan_interface_atomic.h), which has different data types, let's add all the __tsan_atomic* functions to tsan_interface.h.
Differential Revision: http://reviews.llvm.org/D18543
llvm-svn: 265663
Adding an interceptor with two more release+acquire pairs to avoid false positives with dispatch_apply.
Differential Revision: http://reviews.llvm.org/D18722
llvm-svn: 265662
XPC APIs have async callbacks, and we need some more happen-before edges to avoid false positives. This patch add them, plus a test case (sorry for the long boilerplate code, but XPC just needs all that).
Differential Revision: http://reviews.llvm.org/D18493
llvm-svn: 265661
GCD has APIs for event sources, we need some more release-acquire pairs to avoid false positives in TSan.
Differential Revision: http://reviews.llvm.org/D18515
llvm-svn: 265660
In the interceptor for dispatch_sync, we're currently missing synchronization between the callback and the code *after* the call to dispatch_sync. This patch fixes this by adding an extra release+acquire pair to dispatch_sync() and similar APIs. Added a testcase.
Differential Revision: http://reviews.llvm.org/D18502
llvm-svn: 265659
Tom Stellard