| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 204553
|
| |
|
|
| |
llvm-svn: 204552
|
| |
|
|
| |
llvm-svn: 204551
|
| |
|
|
| |
llvm-svn: 204550
|
| |
|
|
|
|
|
|
| |
Some text shows up on stderr when using guard malloc, and this test
was trying to treat that as input to llvm-profdata show. There's no
reason to pipe stderr into show at all here.
llvm-svn: 204549
|
| |
|
|
| |
llvm-svn: 204548
|
| |
|
|
|
|
|
|
| |
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
|
| |
|
|
|
|
| |
No functionnal change.
llvm-svn: 204545
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a label is parsed, check if there is type information available for the
label. If so, check if the symbol is a function. If the symbol is a function
and we are in thumb mode and no explicit thumb_func has been emitted, adjust the
symbol data to indicate that the function definition is a thumb function.
The application of this inferencing is improved value handling in the object
file (the required thumb bit is set on symbols which are thumb functions). It
also helps improve compatibility with binutils.
The one complication that arises from this handling is the MCAsmStreamer. The
default implementation of getOrCreateSymbolData in MCStreamer does not support
tracking the symbol data. In order to support the semantics of thumb functions,
track symbol data in assembly streamer. Although O(n) in number of labels in
the TU, this is already done in various other streamers and as such the memory
overhead is not a practical concern in this scenario.
llvm-svn: 204544
|
| |
|
|
|
|
|
| |
v2f64 values, like other 128-bit values, are returned under VSX in register
vs34 (Altivec register v2).
llvm-svn: 204543
|
| |
|
|
|
|
|
|
|
|
|
| |
operands
When an instruction's operand list does not have a sufficient number of
operands to match with all of the variables that contribute to its
encoding, instead of asserting inside a call to getSubOperandNumber, produce an
informative error.
llvm-svn: 204542
|
| |
|
|
| |
llvm-svn: 204541
|
| |
|
|
|
|
|
| |
is confused with CRLF.
FIXME: line_iterator should be tolerant of CR.
llvm-svn: 204540
|
| |
|
|
|
|
|
|
| |
tool names,"
It was incompatible to standlalone clang build.
llvm-svn: 204539
|
| |
|
|
|
|
|
| |
The cleanup code that removes dead cast instructions only removed them from the
basic block, but didn't delete them. This fix erases them now too.
llvm-svn: 204538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A PHI node usually has only one value/basic block pair per incoming basic block.
In the case of a switch statement it is possible that a following PHI node may
have more than one such pair per incoming basic block. E.g.:
%0 = phi i64 [ 123456, %case2 ], [ 654321, %Entry ], [ 654321, %Entry ]
This is valid and the verfier doesn't complain, because both values are the
same.
Constant hoisting materializes the constant for each operand separately and the
value is still the same, but the variable names have changed. As a result the
verfier can't recognize anymore that they are the same value and complains.
This fix adds special update code for PHI node in constant hoisting to prevent
this corner case.
This fixes <rdar://problem/16394449>
llvm-svn: 204537
|
| |
|
|
|
|
|
|
|
|
|
|
| |
'BuildVectorSDNode::isConstantSplat'
This patch renames method 'isConstantSplat' as 'getConstantSplatValue'
(mainly for consistency reasons), and rewrites its logic to ensure
that we always perform a legal 'cast<ConstantSDNode>'.
Added test shift-combine-crash.ll to verify that DAGCombiner no longer crashes with an assertion failure in the attempt to simplify a vector shift by a vector of all undef counts.
llvm-svn: 204536
|
| |
|
|
|
|
| |
appropriate place, so that we only ask the external source once.
llvm-svn: 204535
|
| |
|
|
|
|
|
|
| |
even though the underlying exception is a trace exception.
<rdar://problem/15243355>
llvm-svn: 204534
|
| |
|
|
| |
llvm-svn: 204533
|
| |
|
|
| |
llvm-svn: 204531
|
| |
|
|
| |
llvm-svn: 204530
|
| |
|
|
|
|
| |
No functional change. This will cleanup a bunch of scan-build warnings.
llvm-svn: 204529
|
| |
|
|
|
|
|
| |
an ID, so this is a noop.
Thanks Manman for catching this!
llvm-svn: 204528
|
| |
|
|
|
|
|
|
|
|
| |
sym_a:
sym_d = sym_a + 1
This is the smallest fix I was able to extract from what got reverted in
r204203.
llvm-svn: 204527
|
| |
|
|
| |
llvm-svn: 204526
|
| |
|
|
|
|
| |
performing typo correction on very short (1 or 2 char) identifiers.
llvm-svn: 204525
|
| |
|
|
| |
llvm-svn: 204524
|
| |
|
|
| |
llvm-svn: 204523
|
| |
|
|
|
|
|
|
|
|
|
| |
We make sure a spill is not hoisted to a hotter outer loop by adding
a condition. Hoist a spill to outer loop if there are multiple dependents
(it can be beneficial if more than one dependents are hoisted) or
if DepSV (the hoisting source) is hotter than SV (the hoisting destination).
rdar://16268194
llvm-svn: 204522
|
| |
|
|
|
|
|
|
| |
This is a bit of a stab in the dark as I'm not sure I've got these
source files compiling correctly locally. (and the warning only
reproduces on a 32bit build anyway)
llvm-svn: 204521
|
| |
|
|
|
|
| |
absolute so relative paths are properly handled in both Windows and Unix.
llvm-svn: 204520
|
| |
|
|
| |
llvm-svn: 204519
|
| |
|
|
|
|
|
|
|
|
| |
Cleanup the current binary testcase for profile data.
- Rename it to something more specific.
- Remove the text comparison.
- Check the output of llvm-profdata show.
llvm-svn: 204518
|
| |
|
|
|
|
|
|
| |
location that the next call emitLocation() would default to. Otherwise
setLocation() may wrongly believe that the current source file didn't
change, when in fact it did.
llvm-svn: 204517
|
| |
|
|
|
|
|
|
| |
Fixes 80-column violation at the same time.
<rdar://problem/15950346>
llvm-svn: 204516
|
| |
|
|
|
|
|
|
| |
Apparently, MSVC has stdint.h now? Let's see if the buildbots complain.
I'm not convinced that the build system is even set up for MSVC to build
this file, but...
llvm-svn: 204515
|
| |
|
|
|
|
|
|
|
| |
Include non-text characters in the magic number so that text files can't
match.
<rdar://problem/15950346>
llvm-svn: 204514
|
| |
|
|
|
|
|
|
|
| |
Include non-text characters in the magic number so that text files can't
match.
<rdar://problem/15950346>
llvm-svn: 204513
|
| |
|
|
|
|
| |
<rdar://problem/15950346>
llvm-svn: 204512
|
| |
|
|
|
|
|
|
| |
No functionality change.
<rdar://problem/15950346>
llvm-svn: 204511
|
| |
|
|
|
|
| |
<rdar://problem/15950346>
llvm-svn: 204510
|
| |
|
|
|
|
|
| |
Creating the file "link.exe" made some confusion, so it's better to
name it lld-link.exe, as we did for CL (clang-cl.exe).
llvm-svn: 204509
|
| |
|
|
| |
llvm-svn: 204508
|
| |
|
|
| |
llvm-svn: 204507
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Type units have no addresses, so there's no need for DW_AT_addr_base.
This removes another relocation from every skeletal type unit and brings
LLVM's skeletal type units in line with GCC's (containing only
GNU_dwo_name (strp), comp_dir (strp), and GNU_pubnames (flag_present)).
Cary's got some ideas about using str_index in the .o file to reduce
those last two relocations (well, replace two relocations with one
relocation (pointing to the string index) and two indicies)
llvm-svn: 204506
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, only regular AArch64 instructions were annotated with SchedRW lists.
This patch does the same for NEON enabling these instructions to be scheduled by
the MIScheduler. Additionally, store operations are now modeled and a few
SchedRW lists were updated for bug fixes (e.g. multiple def operands).
Reviewers: apazos, mcrosier, atrick
Patch by Dave Estes <cestes@codeaurora.org>!
llvm-svn: 204505
|
| |
|
|
|
|
| |
POSIXThread, instead just let StopInfo handle it.
llvm-svn: 204504
|
| |
|
|
| |
llvm-svn: 204503
|
| |
|
|
| |
llvm-svn: 204502
|