| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
forcing VFTableBuilder invocation with virtual function calls or constructors codegen
Previously the vftables were built at the end of the TU in a reverse-to-random order
llvm-svn: 204567
|
| |
|
|
|
|
|
| |
r204562 unwittingly failed tests for some bots. Make those tests work
with both the Itanium and MS ABIs.
llvm-svn: 204566
|
| |
|
|
|
|
|
|
| |
This is a pretty straight forward translation for COFF, we just need to
stick the function in a COMDAT section marked as
IMAGE_COMDAT_SELECT_NODUPLICATES.
llvm-svn: 204565
|
| |
|
|
|
|
|
|
|
|
| |
/Gy is equivalent to -ffunction-sections.
/Gy- is equivalent to -fno-function-sections.
Currently, LLVM doesn't do anything interesting with -ffunction-sections
under WinCOFF.
llvm-svn: 204564
|
| |
|
|
|
|
|
|
| |
/vd2 is not ignored anymore, remove it from the ignored list.
Add a test to ensure that it does the right thing.
llvm-svn: 204563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
ARCMigrate/TransProperties.cpp | 8 -----
AST/MicrosoftMangle.cpp | 1
Analysis/AnalysisDeclContext.cpp | 5 ---
Analysis/LiveVariables.cpp | 14 ----------
Index/USRGeneration.cpp | 10 -------
Sema/Sema.cpp | 33 +++++++++++++++++++++---
Sema/SemaChecking.cpp | 3 --
Sema/SemaDecl.cpp | 20 ++------------
StaticAnalyzer/Checkers/GenericTaintChecker.cpp | 1
9 files changed, 34 insertions(+), 61 deletions(-)
llvm-svn: 204561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
include/llvm/CodeGen/MachineSSAUpdater.h | 1
include/llvm/IR/DebugInfo.h | 3
lib/CodeGen/MachineSSAUpdater.cpp | 10 --
lib/CodeGen/PostRASchedulerList.cpp | 1
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 10 --
lib/IR/DebugInfo.cpp | 12 --
lib/MC/MCAsmStreamer.cpp | 2
lib/Support/YAMLParser.cpp | 39 ---------
lib/TableGen/TGParser.cpp | 16 ---
lib/TableGen/TGParser.h | 1
lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 --
lib/Target/ARM/ARMCodeEmitter.cpp | 12 --
lib/Target/ARM/ARMFastISel.cpp | 84 --------------------
lib/Target/Mips/MipsCodeEmitter.cpp | 11 --
lib/Target/Mips/MipsConstantIslandPass.cpp | 12 --
lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp | 21 -----
lib/Target/NVPTX/NVPTXISelDAGToDAG.h | 2
lib/Target/PowerPC/PPCFastISel.cpp | 1
lib/Transforms/Instrumentation/AddressSanitizer.cpp | 2
lib/Transforms/Instrumentation/BoundsChecking.cpp | 2
lib/Transforms/Instrumentation/MemorySanitizer.cpp | 1
lib/Transforms/Scalar/LoopIdiomRecognize.cpp | 8 -
lib/Transforms/Scalar/SCCP.cpp | 1
utils/TableGen/CodeEmitterGen.cpp | 2
24 files changed, 2 insertions(+), 261 deletions(-)
llvm-svn: 204560
|
| |
|
|
|
|
|
| |
When VSX is available, these instructions should be used in preference to the
older variants that only have access to the scalar floating-point registers.
llvm-svn: 204559
|
| |
|
|
|
|
|
|
| |
benchmarks.
<rdar://problem/16368461>
llvm-svn: 204558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the profile can come from 32-bit machines, we need to check the
pointer size. Change the magic number to facilitate this.
Adds tests for reading 32-bit and 64-bit binaries (both big- and
little-endian). The tests write a binary using printf in RUN lines
(like raw-magic-but-no-header.test). Assuming the bots don't complain,
this seems like a better way forward for testing RawInstrProfReader than
committing binary files.
<rdar://problem/16400648>
llvm-svn: 204557
|
| |
|
|
|
|
|
|
|
| |
Since the profile can come from 32-bit machines, the reader needs to
check the pointer size. Change the magic number to facilitate this.
<rdar://problem/16400648>
llvm-svn: 204556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar, but not identical to what gas does. The logic in MC is to just
compute the symbol table after parsing the entire file. GAS is mixed, given
.type b, @object
a = b
b:
.type b, @function
It will propagate the change and make 'a' a function. Given
.type b, @object
b:
a = b
.type b, @function
the type of 'a' is still object.
Since we do the computation in the end, we produce a function in both cases.
llvm-svn: 204555
|
| |
|
|
|
|
|
| |
out a visible update record for that namespace even if it was never declared in
this module.
llvm-svn: 204554
|
| |
|
|
| |
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
|