| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch closes a gap in the DWARF backend that caused LLVM to drop
debug info for floating point variables that were constant for part of
their scope. Floating point constants are emitted as one or more
DW_OP_constu joined via DW_OP_piece.
This fixes a regression caught by the LLDB testsuite that I introduced
in r262247 when we stopped blindly expanding the range of singular
DBG_VALUEs to span the entire scope and started to emit location lists
with accurate ranges instead.
Also deletes a now-impossible testcase (debug-loc-empty-entries).
<rdar://problem/25448338>
llvm-svn: 265760
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r265734.
Looks like ASan is not happy about it.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11741
Looking.
llvm-svn: 265755
|
|
|
|
|
|
|
| |
Print the mask of the partial mapping as an hexadecimal instead of a
binary value.
llvm-svn: 265754
|
|
|
|
| |
llvm-svn: 265749
|
|
|
|
|
|
| |
helper class.
llvm-svn: 265747
|
|
|
|
|
|
| |
class.
llvm-svn: 265746
|
|
|
|
|
|
|
|
| |
Properly print either the register class or the register bank or a
virtual register.
Get rid of a few ifdefs in the process.
llvm-svn: 265745
|
|
|
|
|
|
|
| |
Teach the target independent code how to take advantage of type
information to get the mapping of an instruction.
llvm-svn: 265739
|
|
|
|
|
|
|
|
|
|
|
|
| |
specific type.
This will be used to find the default mapping of the instruction.
Also, this information is recorded, instead of computed, because it is
expensive from a type to know which register bank maps it.
Indeed, we need to iterate through all the register classes of all the
register banks to find the one that maps the given type.
llvm-svn: 265736
|
|
|
|
|
|
|
|
|
|
|
| |
method.
NFC.
The refactoring intends to make the code more readable and expose
more features to potential derived classes.
llvm-svn: 265735
|
|
|
|
| |
llvm-svn: 265734
|
|
|
|
| |
llvm-svn: 265733
|
|
|
|
|
|
|
|
|
| |
from a register.
On top of duplicating the logic, it was buggy! It would assert on
physical registers, since MachineRegisterInfo does not have any
information regarding register classes/banks for them.
llvm-svn: 265727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
schedule
Summary:
EHPad BB are not entered the classic way and therefor do not need to be placed after their predecessors. This patch make sure EHPad BB are not chosen amongst successors to form chains, and are selected as last resort when selecting the best candidate.
EHPad are scheduled in reverse probability order in order to have them flow into each others naturally.
Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17625
llvm-svn: 265726
|
|
|
|
|
|
|
| |
Now, RegBankSelect will happen after the IRTranslation and the target
may optionally add additional passes in between.
llvm-svn: 265716
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the access to MRI and TRI.
llvm-svn: 265701
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 265695
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 265657
|
|
|
|
|
|
| |
NFC.
llvm-svn: 265643
|
|
|
|
|
|
| |
NFC.
llvm-svn: 265642
|
|
|
|
|
|
|
|
|
| |
The iterators of SmallPtrSet SpillsInSubTreeMap[Child].first may be
invalidated when SpillsInSubTreeMap grows. Rearrange the code to
ensure the grow of SpillsInSubTreeMap only happens before getting
the iterators of the SmallPtrSet.
llvm-svn: 265639
|
|
|
|
|
|
| |
an unused function parameter"
llvm-svn: 265638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clarify what this RemapFlag actually means.
- Change the flag name to match its intended behaviour.
- Clearly document that it's not supposed to affect globals.
- Add a host of FIXMEs to indicate how to fix the behaviour to match
the intent of the flag.
RF_IgnoreMissingLocals should only affect the behaviour of
RemapInstruction for function-local operands; namely, for operands of
type Argument, Instruction, and BasicBlock. Currently, it is *only*
passed into RemapInstruction calls (and the transitive MapValue calls
that it makes).
When I split Metadata from Value I didn't understand the flag, and I
used it in a bunch of places for "global" metadata.
This commit doesn't have any functionality change, but prepares to
cleanup MapMetadata and MapValue.
llvm-svn: 265628
|
|
|
|
|
|
|
|
|
|
|
| |
getInstrMapping.
This implementation requires that the target implemented
getRegBankFromRegClass.
Indeed, the implementation uses the register classes for the encoding
constraints for the instructions to deduce the mapping of a value.
llvm-svn: 265624
|
|
|
|
|
|
|
| |
The previous method to get the size was too simple and could fail for
physical registers.
llvm-svn: 265620
|
|
|
|
|
|
|
| |
Use MapVector instead of DenseMap for MergeableSpillsMap so it will be
iterated in determined order.
llvm-svn: 265610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on a register bank.
This will be used by the register bank select pass to assign register banks
for generic virtual registers.
This was originally committed as r265573 but broke at least one windows bot.
The problem with the windows bot was that it was using a copy constructor for
the InstructionMappings class and could not synthesize it. Actually, the fact
that this class is not copy constructable is expected and the compiler should
use the move assignment constructor. Marking the problematic assignment
explicitly as using the move constructor has its own problems.
Indeed, with recent clang we get a warning that we may prevent the elision of
the copy by the compiler. A proper fix for both compilers would be to change the
API of getPossibleInstrMapping to take a InstructionMappings as input/output
parameter. This does not feel natural and since GISel is not used on windows
yet, I chose to workaround the problem by not compiling the problematic code on
windows.
llvm-svn: 265604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).
This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.
As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
llvm-svn: 265602
|
|
|
|
|
|
| |
NFC.
llvm-svn: 265596
|
|
|
|
|
|
|
|
|
|
|
| |
instruction on a register bank. This will be used by the register bank select
pass to assign register banks for generic virtual registers." and the follow-on
commits while I find out a way to fix the win7 bot:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19882
This reverts commit r265578, r265581, r265584, and r265585.
llvm-svn: 265587
|
|
|
|
| |
llvm-svn: 265583
|
|
|
|
|
|
|
|
|
| |
helper class.
The default constructor creates invalid (isValid() == false) instances
and may be used to communicate that a mapping was not found.
llvm-svn: 265581
|
|
|
|
|
|
|
| |
The previous method to get the size was too simple and could fail for
physical registers.
llvm-svn: 265578
|
|
|
|
|
|
|
|
|
| |
on a register bank.
This will be used by the register bank select pass to assign register banks
for generic virtual registers.
llvm-svn: 265573
|
|
|
|
|
|
|
|
| |
helper class.
This checks that all the register operands get a proper mapping.
llvm-svn: 265563
|
|
|
|
|
|
|
|
|
| |
class.
The method checks that the value is fully defined accross the different partial
mappings and that the partial mappings are compatible between each other.
llvm-svn: 265556
|
|
|
|
|
|
|
| |
This verifies that the PartialMapping can be accomadated into the related
register bank.
llvm-svn: 265555
|
|
|
|
| |
llvm-svn: 265553
|
|
|
|
|
|
| |
GlobalISel is not built.
llvm-svn: 265548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when DenseMap growed and moved memory. I verified it fixed the bootstrap
problem on x86_64-linux-gnu but I cannot verify whether it fixes
the bootstrap error on clang-ppc64be-linux. I will watch the build-bot
result closely.
Replace analyzeSiblingValues with new algorithm to fix its compile
time issue. The patch is to solve PR17409 and its duplicates.
analyzeSiblingValues is a N x N complexity algorithm where N is
the number of siblings generated by reg splitting. Although it
causes siginificant compile time issue when N is large, it is also
important for performance since it removes redundent spills and
enables rematerialization.
To solve the compile time issue, the patch removes analyzeSiblingValues
and replaces it with lower cost alternatives containing two parts. The
first part creates a new spill hoisting method in postOptimization of
register allocation. It does spill hoisting at once after all the spills
are generated instead of inside every instance of selectOrSplit. The
second part queries the define expr of the original register for
rematerializaiton and keep it always available during register allocation
even if it is already dead. It deletes those dead instructions only in
postOptimization. With the two parts in the patch, it can remove
analyzeSiblingValues without sacrificing performance.
Differential Revision: http://reviews.llvm.org/D15302
llvm-svn: 265547
|
|
|
|
|
|
|
| |
Make it obvious that the argument cannot be nullptr.
Remove an unnecessary nullptr check in initRegState.
llvm-svn: 265511
|
|
|
|
| |
llvm-svn: 265509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While preserving the return value for @llvm.experimental.deoptimize at
the IR level is useful during mid-level optimization, doing so at the
machine instruction level requires generating some extra code and a
return that is non-ideal. This change has LLVM lower
```
%val = call @llvm.experimental.deoptimize
ret %val
```
to effectively
```
call @__llvm_deoptimize()
unreachable
```
instead.
llvm-svn: 265502
|
|
|
|
|
|
|
|
|
| |
As part of the TRI argument of addRegBankCoverage we already have access to
the TargetRegisterClass through the ID of that register class.
Therefore, there is no point in needing a TargetRegisterClass instance,
the ID is enough to get to it.
llvm-svn: 265487
|
|
|
|
|
|
|
| |
Bionic has a defined thread-local location for the stack protector
cookie. Emit a direct load instead of going through __stack_chk_guard.
llvm-svn: 265481
|