mcintyre@artecon.artecon.UUCP (C. Kevin Mcintyre) (03/07/87)
I am looking for some source/suggestions/clues/etc... (whatever) for
Peephole Optimizers. I have looked at the Aho Dragon book but it is
somewhat lacking in this area. As far as I can tell it is just a matter
of "string" matching and replacement. I am especially interested in how
the "big" compiler writing companies do their peephole optimizing if
any of them read this newsgroup. Any help will be greatly appreciated
and I will post the results/suggestions back to the net if the
interest is great enough.
--Thanks, Kevin.
Reply with any information to uucp path sdcsvax!hp-sdd!artecon!mcintyre
[All of the peepholers I ever fooled with were pretty standard pattern
matchers with some sort of data structure to let you move code around to
do tail merging and loop flipping. It also seems that about half of the
peephole transformations are quite machine independent, like removing
redundant moves or jumps to jumps, and the other half are completely machine
specific, like taking advantage of pecular address modes or loop closing
instructions. Feel free to cc: interesting responses to compilers. -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (03/13/87)
In article <373@artecon.artecon.UUCP> Kevin writes: >I am looking for some source/suggestions/clues/etc... (whatever) for >Peephole Optimizers. ... One project I worked on was a Davidson Frazer style Peephole Optimizer. This takes an incoming stream of instructions inside a basic block (using an infinite register set), 1) expands them into a symbolic description of their effect (register transfer lists) 2) keeps track of register values not killed, reusing them where possible. 3) As a side effect of #2, constructs links from instructions to instructions that they logically depend on (ie. because the prior instruction computes a value the latter instruction uses) 4) collapses pairs of logically related instructions by composition of the register transfer list - if the result can be represented by a valid instruction, replace pair with that. 5) assignment of virtual registers to real registers. The original researches goal was retargetability; my experience was that it was a little slow, but quite thorough, getting you the results of a lot of ad-hoc fixups with a few solid techniques. Note that the original work was done using a series of textual filters for 1-5. You can do a lot better in terms of speed by using internal linked list representations of register transfer lists. The references to the original paper is: TOPLAS, april '80 pg 191, Davidson, Frazer 'Implementation of a Retargetable Peephole Analyser' Max -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request