[llvm-commits] [llvm] r158204 - in /llvm/trunk: lib/Target/PowerPC/CMakeLists.txt lib/Target/PowerPC/PPC.h lib/Target/PowerPC/PPCBranchSelector.cpp lib/Target/PowerPC/PPCCTRLoops.cpp lib/Target/PowerPC/PPCInstr64Bit.td lib/Target/PowerPC/PPCInstrFormats.td lib/Target/PowerPC/PPCInstrInfo.cpp lib/Target/PowerPC/PPCInstrInfo.td lib/Target/PowerPC/PPCTargetMachine.cpp test/CodeGen/PowerPC/ctrloops.ll

[Hal Finkel]

On Fri, 08 Jun 2012 10:55:30 -0700
Chris Lattner <clattner at apple.com> wrote:

> 
> On Jun 8, 2012, at 8:38 AM, Hal Finkel wrote:
> 
> > Author: hfinkel
> > Date: Fri Jun  8 10:38:21 2012
> > New Revision: 158204
> > 
> > URL: http://llvm.org/viewvc/llvm-project?rev=158204&view=rev
> > Log:
> > Add the PPCCTRLoops pass: a PPC machine-code-level optimization
> > pass to form CTR-based loop branching code.
> > 
> > This pass is derived from the Hexagon HardwareLoops pass. The only
> > significant enhancement over the Hexagon pass is that PPCCTRLoops
> > will also attempt to delete the replaced add and compare operations
> > if they are no longer otherwise used. Also, invalid preheader
> > DebugLoc is not used.
> 
> Silly question, but how impossible would it be to abstract both of
> these out to a target-independent hardware loop formation pass, which
> would be parameterized by a new TargetHardwareLoopInfo class?

This is not a silly question, and I think that we should definitely do
this. As I first step toward this, I submitted a (belated) review of
the Hexagon pass. Once the two passes are brought into alignment in
terms of functionality (and bug fixes), I think it will be very easy to
abstract away the differences (which, new things aside, are actually
quite minor).

 -Hal

> 
> -Chris



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory