[PATCH, RFC] DAG postprocessing phase for PPC

Bill Schmidt wschmidt at linux.vnet.ibm.com
Mon Feb 18 14:00:00 PST 2013


This patch implements the PPCDAGToDAGISel::PostprocessISelDAG virtual
method to perform post-selection peephole optimizations on the DAG
representation.

One optimization is implemented here:  folds to clean up complex
addressing expressions for thread-local storage and medium code
model.  It will also be useful for large code model sequences when
those are added later.  I originally thought about doing this on the
MI representation prior to register assignment, but it's difficult to
do effective global dead code elimination at that point.  DCE is
trivial on the DAG representation.

A typical example of a candidate code sequence in assembly:

   addis 3, 2, globalvar at toc@ha
   addi  3, 3, globalvar at toc@l
   lwz   5, 0(3)

When the final instruction is a load or store with an immediate offset
of zero, the offset from the add-immediate can replace the zero,
provided the relocation information is carried along:

   addis 3, 2, globalvar at toc@ha
   lwz   5, globalvar at toc@l(3)

Since the addi can in general have multiple uses, we need to only
delete the instruction when the last use is removed.

I'm planning to add another fold shortly that was recently disabled
in PPCISelLowering.cpp because it was undone by constant folding
(lowering BUILD_VECTOR into an add of two identical splats).  The DAG
representation is the right place for the fold, so long as it occurs
after the constant folding that currently makes it moot.

I reorganized the target flags in PPC.h to be more useful (flag 2 was
unused, so I shifted the flags over to make an extra bit available in
the field used for distinct values).  I think some of the other bits
used as "flags" should be reconsidered in the future, as some of them
appear to be mutually exclusive and the encoding could be more
efficient.

I'm posting this as an RFC in case there are objections with doing
this in a new pass, suggestions for a better place to do this, etc.
If no objections, I'll commit it shortly.

Thanks!
Bill
-- 
Bill Schmidt, Ph.D.
IBM Advance Toolchain for PowerLinux
IBM Linux Technology Center
wschmidt at us.ibm.com
wschmidt at linux.vnet.ibm.com





-------------- next part --------------
A non-text attachment was scrubbed...
Name: peephole-2013-02-18.patch
Type: text/x-patch
Size: 17384 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130218/3a8412b5/attachment.bin>


More information about the llvm-commits mailing list