| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19509
llvm-svn: 267593
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html
I'll recommit if we get consensus that it's the right direction.
llvm-svn: 261567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.
- Downcast to ilist_node in iplist::getNextNode() and getPrevNode() so
that ilist_node::getIterator() is still available.
- Add it back as MachineInstr::getInstrIterator(). This matches the
naming in MachineBasicBlock.
- Add MachineInstr::getBundleIterator(). This is explicitly called
"bundle" (not matching MachineBasicBlock) to disintinguish it clearly
from ilist_node::getIterator().
- Update all calls. Some of these I switched to `auto` to remove
boiler-plate, since the new name is clear about the type.
There was one call I updated that looked fishy, but it wasn't clear what
the right answer was. This was in X86FrameLowering::inlineStackProbe(),
added in r252578 in lib/Target/X86/X86FrameLowering.cpp. I opted to
leave the behaviour unchanged, but I'll reply to the original commit on
the list in a moment.
llvm-svn: 261504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two things out of the ordinary in this commit. First, I made
a loop obviously "infinite" in HexagonInstrInfo.cpp. After checking if
an instruction was at the beginning of a basic block (in which case,
`break`), the loop decremented and checked the iterator for `nullptr` as
the loop condition. This has never been possible (the prev pointers are
always been circular, so even with the weird ilist/iplist
implementation, this isn't been possible), so I removed the condition.
Second, in HexagonAsmPrinter.cpp there was another case of comparing a
`MachineBasicBlock::instr_iterator` against `MachineBasicBlock::end()`
(which returns `MachineBasicBlock::iterator`). While not incorrect,
it's fragile. I switched this to `::instr_end()`.
All that said, no functionality change intended here.
llvm-svn: 250778
|
|
|
|
| |
llvm-svn: 244402
|
|
|
|
|
|
| |
files. Removing unused function getSubtargetInfo from HexagonMCCodeEmitter.cpp Removing deletion of copy construction and assignment operator since parent already deletes it.
llvm-svn: 239744
|
|
|
|
|
|
|
|
|
| |
The induction variable in the vectorized loop wasn't
recognized properly, so a hardware loop wasn't generated.
Differential Revision: http://reviews.llvm.org/D9722
llvm-svn: 237388
|
|
|
|
|
|
|
|
|
|
|
| |
After converting a loop to a hardware loop, the pass should remove
any unnecessary instructions from the old compare-and-branch
code. This patch removes a dead constant assignment that was
used in the compare instruction.
Differential Revision: http://reviews.llvm.org/D9720
llvm-svn: 237373
|
|
|
|
|
|
|
|
| |
If the loop trip count may underflow or wrap, the compiler should
not generate a hardware loop since the trip count will be
incorrect.
llvm-svn: 237365
|
|
|
|
|
|
|
|
| |
loop1 is for the outer loop and loop0 is for the inner loop.
Differential Revision: http://reviews.llvm.org/D9680
llvm-svn: 237266
|
|
|
|
|
|
|
|
|
| |
The hardware loop pass should try to generate a hardware loop
instruction when the original loop has a critical edge.
Differential Revision: http://reviews.llvm.org/D9678
llvm-svn: 237258
|
|
|
|
|
|
|
|
|
| |
Refactored parts of the hardware loop pass to generate
more. Also, added more tests.
Differential Revision: http://reviews.llvm.org/D9568
llvm-svn: 236896
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improved the AnalyzeBranch, InsertBranch, and RemoveBranch
functions in order to handle more of our branch instructions.
This requires changes to analyzeCompare and PredicateInstructions.
Specifically, we've added support for new value compare jumps,
improved handling of endloop, added more compare instructions,
and improved support for predicate instructions.
Differential Revision: http://reviews.llvm.org/D9559
llvm-svn: 236876
|
|
|
|
|
|
| |
std::abs works just fine and we're already using it in many places. NFC intended.
llvm-svn: 231696
|
|
|
|
| |
llvm-svn: 228326
|
|
|
|
| |
llvm-svn: 228318
|
|
|
|
|
|
| |
off of the machine function.
llvm-svn: 227837
|
|
|
|
| |
llvm-svn: 226013
|
|
|
|
|
|
| |
information. Updating references.
llvm-svn: 226003
|
|
|
|
| |
llvm-svn: 224612
|
|
|
|
| |
llvm-svn: 224556
|
|
|
|
| |
llvm-svn: 224552
|
|
|
|
| |
llvm-svn: 224550
|
|
|
|
| |
llvm-svn: 224391
|
|
|
|
| |
llvm-svn: 223967
|
|
|
|
| |
llvm-svn: 223821
|
|
|
|
| |
llvm-svn: 222849
|
|
|
|
| |
llvm-svn: 222771
|
|
|
|
| |
llvm-svn: 222571
|
|
|
|
|
|
|
|
| |
Reviewers: adasgupt, jverma, sidneym
Differential Revision: http://reviews.llvm.org/D5025
llvm-svn: 216667
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. Hexagon edition
llvm-svn: 207508
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Target/...
edition.
llvm-svn: 206842
|
|
|
|
|
|
|
|
|
|
| |
operator* on the by-operand iterators to return a MachineOperand& rather than
a MachineInstr&. At this point they almost behave like normal iterators!
Again, this requires making some existing loops more verbose, but should pave
the way for the big range-based for-loop cleanups in the future.
llvm-svn: 203865
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
|
|
|
| |
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
llvm-svn: 200018
|
|
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
|
|
|
| |
llvm-svn: 190770
|
|
|
|
|
|
| |
size.
llvm-svn: 186274
|
|
|
|
| |
llvm-svn: 180885
|
|
|
|
| |
llvm-svn: 180133
|
|
|
|
| |
llvm-svn: 178462
|
|
|
|
| |
llvm-svn: 178141
|
|
|
|
|
|
|
|
| |
- variety of compare instructions,
- loops with no preheader,
- arbitrary lower and upper bounds.
llvm-svn: 174904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
|
| |
In particular, check if MachineBasicBlock::iterator is end() before
using it to call getDebugLoc();
See also this thread on llvm-commits:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155914.html
llvm-svn: 169634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
|
|
| |
This way of using getNextOperandForReg() was unlikely to work as
intended. We don't give any guarantees about the order of operands in
the use-def chains, so looking only at operands following a given
operand in the chain doesn't make sense.
llvm-svn: 161542
|
|
|
|
| |
llvm-svn: 157885
|