Fix "left shift of negative value -1" introduced by r294805

llvm-svn: 294843

[Hexagon] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 289907

Fix spelling mistakes in Hexagon target comments. NFC.

Identified by Pedro Giffuni in PR27636.

llvm-svn: 287248

[Hexagon] Separate Hexagon subreg indices for different register classes

For pairs of 32-bit registers: isub_lo, isub_hi.
For pairs of vector registers: vsub_lo, vsub_hi.

Add generic subreg indices

[Hexagon] Separate Hexagon subreg indices for different register classes

For pairs of 32-bit registers: isub_lo, isub_hi.
For pairs of vector registers: vsub_lo, vsub_hi.

Add generic subreg indices: ps_sub_lo, ps_sub_hi, and a function
HexagonRegisterInfo::getHexagonSubRegIndex(RegClass, GenericSubreg)
that returns the appropriate subreg index for RegClass.

llvm-svn: 286377

show more ...

Use StringRef in Pass/PassManager APIs (NFC)

llvm-svn: 283004

Make analyzeBranch family of instruction names consistent

analyzeBranch was renamed to use lowercase first, rename
the related set to match.

llvm-svn: 281506

This reapplies r281304. The issue was that I had missed
to copy the new isAdd field in the tablegen data structure.

llvm-svn: 281447

Revert of r281304 as it is causing build bot failures in hexagon
hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.

llvm-svn: 281306

This adds a new field isAdd to MCInstrDesc. The ARM and Hexagon instruction
descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.

Patch

This adds a new field isAdd to MCInstrDesc. The ARM and Hexagon instruction
descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.

Patch by Sam Parker and Sjoerd Meijer.

Differential Revision: https://reviews.llvm.org/D23601

llvm-svn: 281304

show more ...

MachineLoop: add methods findLoopControlBlock and findLoopPreheader

This adds two new utility functions findLoopControlBlock and findLoopPreheader
to MachineLoop and MachineLoopInfo. These functions

MachineLoop: add methods findLoopControlBlock and findLoopPreheader

This adds two new utility functions findLoopControlBlock and findLoopPreheader
to MachineLoop and MachineLoopInfo. These functions are refactored and taken
from the Hexagon target as they are target independent; thus this is intendend to
be a non-functional change.

Differential Revision: https://reviews.llvm.org/D22959

llvm-svn: 278661

show more ...

[Hexagon] Allow non-returning calls in hardware loops

llvm-svn: 278416

[Hexagon] Use integer instructions for floating point immediates

Floating point instructions use general purpose registers, so the few
instructions that can put floating point immediates into regist

[Hexagon] Use integer instructions for floating point immediates

Floating point instructions use general purpose registers, so the few
instructions that can put floating point immediates into registers are,
in fact, integer instruction. Use them explicitly instead of having
pseudo-instructions specifically for dealing with floating point values.

Simplify the constant loading instructions (from sdata) to have only two:
one for 32-bit values and one for 64-bit values: CONST32 and CONST64.

llvm-svn: 278244

show more ...

[Hexagon] Find speculative loop preheader in hardware loop generation

Before adding a new preheader block, check if there is a candidate block
where the loop setup could be placed speculatively. Thi

[Hexagon] Find speculative loop preheader in hardware loop generation

Before adding a new preheader block, check if there is a candidate block
where the loop setup could be placed speculatively. This will be off by
default.

llvm-svn: 276919

show more ...

Rename AnalyzeBranch* to analyzeBranch*.

Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetIn

Rename AnalyzeBranch* to analyzeBranch*.

Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetInstrInfo's analyzeCompare and analyzeSelect.

Reviewers: tstellarAMD, mcrosier

Subscribers: mcrosier, jholewinski, jfb, arsenm, dschuff, jyknight, dsanders, nemanjai

Differential Revision: https://reviews.llvm.org/D22409

llvm-svn: 275564

show more ...

CodeGen: Use MachineInstr& in TargetInstrInfo, NFC

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when th

CodeGen: Use MachineInstr& in TargetInstrInfo, NFC

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when the argument is expected to be a valid MachineInstr. This is a
general API improvement.

Although it would be possible to do this one function at a time, that
would demand a quadratic amount of churn since many of these functions
call each other. Instead I've done everything as a block and just
updated what was necessary.

This is mostly mechanical fixes: adding and removing `*` and `&`
operators. The only non-mechanical change is to split
ARMBaseInstrInfo::getOperandLatencyImpl out from
ARMBaseInstrInfo::getOperandLatency. Previously, the latter took a
`MachineInstr*` which it updated to the instruction bundle leader; now,
the latter calls the former either with the same `MachineInstr&` or the
bundle leader.

As a side effect, this removes a bunch of MachineInstr* to
MachineBasicBlock::iterator implicit conversions, a necessary step
toward fixing PR26753.

Note: I updated WebAssembly, Lanai, and AVR (despite being
off-by-default) since it turned out to be easy. I couldn't run tests
for AVR since llc doesn't link with it turned on.

llvm-svn: 274189

show more ...

Add optimization bisect opt-in calls for Hexagon passes

Differential Revision: http://reviews.llvm.org/D19509

llvm-svn: 267593

Revert "CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC"

This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week

Revert "CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC"

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

show more ...

CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC

Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.

- Downcast to ilist_node

CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC

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

show more ...

Hexagon: Remove implicit ilist iterator conversions, NFC

There are two things out of the ordinary in this commit. First, I made
a loop obviously "infinite" in HexagonInstrInfo.cpp. After checking

Hexagon: Remove implicit ilist iterator conversions, NFC

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

show more ...

Fix some comment typos.

llvm-svn: 244402

[Hexagon] Moving pass declarations out of header and in to implementation files. Removing unused function getSubtargetInfo from HexagonMCCodeEmitter.cpp Removing deletion of copy construction and a

[Hexagon] Moving pass declarations out of header and in to implementation files. Removing unused function getSubtargetInfo from HexagonMCCodeEmitter.cpp Removing deletion of copy construction and assignment operator since parent already deletes it.

llvm-svn: 239744

show more ...

[Hexagon] Generate hardware loop for a vectorized loop

The induction variable in the vectorized loop wasn't
recognized properly, so a hardware loop wasn't generated.

Differential Revision: http://r

[Hexagon] Generate hardware loop for a vectorized loop

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

show more ...

[Hexagon] Remove dead constant assignment in hardware loop pass

After converting a loop to a hardware loop, the pass should remove
any unnecessary instructions from the old compare-and-branch
code.

[Hexagon] Remove dead constant assignment in hardware loop pass

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

show more ...

[Hexagon] Check for underflow/wrap in hardware loop pass

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-

[Hexagon] Check for underflow/wrap in hardware loop pass

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

show more ...

[Hexagon] Generate loop1 instruction for nested loops

loop1 is for the outer loop and loop0 is for the inner loop.

Differential Revision: http://reviews.llvm.org/D9680

llvm-svn: 237266