| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. PowerPC edition
llvm-svn: 207504
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. R600 edition
llvm-svn: 207503
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. Sparc edition
llvm-svn: 207502
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. XCore edition
llvm-svn: 207501
|
|
|
|
|
|
| |
is introduced by r207485.
llvm-svn: 207500
|
|
|
|
| |
llvm-svn: 207499
|
|
|
|
|
|
| |
E.g. Mask like <-1, -1, 1, ...> will generate incorrect EXT index.
llvm-svn: 207485
|
|
|
|
|
|
|
| |
opcode so there's no reason to use the target namespace for it
rather than TargetOpcode.
llvm-svn: 207475
|
|
|
|
| |
llvm-svn: 207474
|
|
|
|
| |
llvm-svn: 207473
|
|
|
|
| |
llvm-svn: 207472
|
|
|
|
|
|
|
|
|
|
|
| |
Seems at some point the intent was to emit fission ranges_base as unique
per CU but the code today emits ranges_base as the start of the ranges
section for all CUs being compiled and all the ranges_base relative
addresses are relative to that. So removing this dead code and leaving
the status quo until there's a reason to change it (perhaps something's
faster if it has distinct ranges for each CU).
llvm-svn: 207464
|
|
|
|
|
|
|
|
| |
clang directly from the LLVM test suite! That doesn't work. I've
followed up on the review thread to try and get a viable solution sorted
out, but trying to get the tree clean here.
llvm-svn: 207462
|
|
|
|
|
|
|
|
|
|
| |
FrameEntry doesn't need to hold a reference to the section it is
located in. Instead, pass DataExtractor as an argument of parsing
function.
No functionality change.
llvm-svn: 207461
|
|
|
|
|
|
| |
Based on code review by Eric Christopher on r207323
llvm-svn: 207460
|
|
|
|
| |
llvm-svn: 207459
|
|
|
|
| |
llvm-svn: 207458
|
|
|
|
|
|
|
|
|
|
| |
There is no need to keep the whole contents of .debug_aranges section
in memory when we build address ranges table. Memory optimization that
used to be in this code (precalculate the size of vector of ranges before
filling it) is not really needed - later we will compact and resize this
vector anyway.
llvm-svn: 207457
|
|
|
|
|
|
|
|
| |
(Clang doesn't warn here because it knows the string is benign - the
assert still checks what it's intended to - though putting the correct
parens does make clang-format format the code a little better)
llvm-svn: 207456
|
|
|
|
|
|
| |
Patch by Jan Vesely <jan.vesely@rutgers.edu>.
llvm-svn: 207455
|
|
|
|
| |
llvm-svn: 207452
|
|
|
|
|
|
|
|
|
| |
Since all 4 ctor calls in DwarfDebug just pass in a trivially
constructed DIE with the right tag type, sink the tag selection down
into the Dwarf*Unit ctors (removing the argument entirely from callers
in DwarfDebug) and initialize the DIE member in DwarfUnit.
llvm-svn: 207448
|
|
|
|
| |
llvm-svn: 207447
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When evaluating an assembly expression for a relocation, we want to
stop at MCSymbols that are in the symbol table, even if they are variables.
This is needed since the semantics may require that the relocation use them.
That is not the case when computing the value of a symbol in the symbol table.
There are no relocations in this case and we have to keep going until we hit
a section or find out that the expression doesn't have an assembly time
value.
llvm-svn: 207445
|
|
|
|
| |
llvm-svn: 207444
|
|
|
|
|
|
|
|
|
|
| |
Now that the subtle constructScopeDIE has been refactored into two
functions - one returning memory to take ownership of, one returning a
pointer to already owning memory - push unique_ptr through more APIs.
I think this completes most of the unique_ptr ownership of DIEs.
llvm-svn: 207442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While refactoring out constructScopeDIE into two functions I realized we
were emitting DW_AT_object_pointer in the inlined subroutine when we
didn't need to (GCC doesn't, and the abstract subprogram definition has
the information already).
So here's the refactoring and the bug fix. This is one step of
refactoring to remove some subtle memory ownership semantics. It turns
out the original constructScopeDIE returned ownership in its return
value in some cases and not in others. The split into two functions now
separates those two semantics - further cleanup (unique_ptr, etc) will
follow.
llvm-svn: 207441
|
|
|
|
| |
llvm-svn: 207440
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r207287, reapplying r207286.
I'm hoping that declaring an explicit struct and instantiating
`addBlockEdges()` directly works around the GCC crash from r207286.
This is a lot more boilerplate, though.
llvm-svn: 207438
|
|
|
|
|
|
| |
X86TargetLowering::getScalingFactorCost.
llvm-svn: 207432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit provides the necessary C/C++ APIs and infastructure to enable fine-
grain progress report and safe suspension points after each pass in the pass
manager.
Clients can provide a callback function to the pass manager to call after each
pass. This can be used in a variety of ways (progress report, dumping of IR
between passes, safe suspension of threads, etc).
The run listener list is maintained in the LLVMContext, which allows a multi-
threaded client to be only informed for it's own thread. This of course assumes
that the client created a LLVMContext for each thread.
This fixes <rdar://problem/16728690>
llvm-svn: 207430
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3523
llvm-svn: 207428
|
|
|
|
| |
llvm-svn: 207426
|
|
|
|
|
|
|
| |
No functionality change. This removes the last use of AliasedSymbol in
ELFObjectWriter.cpp.
llvm-svn: 207424
|
|
|
|
|
|
| |
D subregister.
llvm-svn: 207423
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 207421
|
|
|
|
|
|
|
|
| |
It's bad enough that I have to look up 5 different levels of TableGen class
definitions to work out what bits go where in a simple NEON instruction anyway,
without having to keep track of umpteen unused parameters.
llvm-svn: 207420
|
|
|
|
|
|
|
|
|
|
|
|
| |
The symbol table itself has no relocations, so it is not possible to represent
things like
a = undefined + 1
With the patch we just omit these variables. That matches the behaviour of the
gnu assembler.
llvm-svn: 207419
|
|
|
|
| |
llvm-svn: 207414
|
|
|
|
|
|
|
|
|
|
| |
X86_MAX_OPERANDS is changed to unsigned.
Also, add range-based for loops for affected loops. This in turn
needed an ArrayRef instead of a pointer-to-array in
InternalInstruction.
llvm-svn: 207413
|
|
|
|
|
|
|
|
|
|
|
| |
Someone couldn't bear to have a completely orthogonal set of floating-point
registers, so we've got some instructions that only accept v0-v15 (coming in
ARMv9, V128_prime: you're allowed v2, v3, v5, v7, ...).
Anyway, we were permitting even the out of range registers during assembly
(CodeGen handled it correctly). This adds a diagnostic.
llvm-svn: 207412
|
|
|
|
|
|
|
| |
just handles the pre-DFS case. Also add some test cases for this case to
make sure it works.
llvm-svn: 207411
|
|
|
|
|
|
|
|
| |
contract (and be much more useful). It now provides exactly the
post-order traversal a caller might need to perform on newly formed
SCCs.
llvm-svn: 207410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mapping from a basic block to an incoming value, either for removal or
just lookup, is linear in the number of predecessors, and we were doing
this for every entry in the 'Preds' list which is in many cases almost
all of them!
Unfortunately, the fixes are quite ugly. PHI nodes just don't make this
operation easy. The efficient way to fix this is to have a clever
'remove_if' operation on PHI nodes that lets us do a single pass over
all the incoming values of the original PHI node, extracting the ones we
care about. Then we could quickly construct the new phi node from this
list. This would remove the remaining underlying quadratic movement of
unrelated incoming values and the need for silly backwards looping to
"minimize" how often we hit the quadratic case.
This is the last obvious fix for PR19499. It shaves another 20% off the
compile time for me, and while UpdatePHINodes remains in the profile,
most of the time is now stemming from the well known inefficiencies of
LVI and jump threading.
llvm-svn: 207409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by avoiding inlining massive switches merely because they have no
instructions in them. These switches still show up where we fail to form
lookup tables, and in those cases they are actually going to cause
a very significant code size hit anyways, so inlining them is not the
right call. The right way to fix any performance regressions stemming
from this is to enhance the switch-to-lookup-table logic to fire in more
places.
This makes PR19499 about 5x less bad. It uncovers a second compile time
problem in that test case that is unrelated (surprisingly!).
llvm-svn: 207403
|
|
|
|
| |
llvm-svn: 207399
|
|
|
|
| |
llvm-svn: 207397
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
|
|
| |
Use C++11 range-based loops rather than explicit constructors. NFC.
llvm-svn: 207393
|
|
|
|
|
|
| |
our own portability system to cope without snprintf.
llvm-svn: 207389
|