[LLVMdev] GSoC 2011: Superoptimization for LLVM IR
Duncan Sands
baldrick at free.fr
Fri Apr 8 02:04:36 PDT 2011
Hi Rafael, don't forget to submit your proposal to GSOC (via the GSOC web-page)
- the deadline is today!
>
> It sounds like you are planning to follow the approach of Joshi, Nelson and
> Randall ("Denali: A Goal-directed Superoptimizer") in that you don't intend
> to exhaustively enumerate all possible code sequences, and see if they are
> the same as the original only better; but instead start from the original code
> sequence and repeatedly apply transformations that change code to equivalent
> code, looking to see if you can eventually get something better than the
> original. Is that right?
>
>
> Exactly. If we can use axioms/transformations/identities which don't modify the
> code behavior, but just tries to interpret instruction semantics in a different
> way, so as to find another (and hopefully simpler) instructions to do the same
> job, the role of the SAT prover is no longer necessary, since the search space
> is constrained to expressions which are semantically equivalent.
>
> Example:
> Transformation: (ADD Operand_A, Contant 0) <- equivalent to-> Operand_A
>
> Using this transformation, the search algorithm now can simplify "add A with 0"
> to "A" or, what may look initially not so useful, transform any operand A into
> an add with A plus 0. Later, this is important to prove we can use an add
> instruction to load any operand. Well, I think you got the idea of using a set
> of axioms... this, in practice, is important to prove an arbitrary sequence A is
> equivalent to SequenceB, and, if B is shorter than A, use B instead. Speaking
> of implementation, there will be a big list of transformations and a "for" loop
> trying each transformation and recursively applying more transformations, until
> we can show a code sequence is equivalent to another. This is a short overview
> of the algorithm and how I worked in this area. If you prefer another approach
> described formally in another paper, I can study it and use another algorithm.
I am fine with this approach, even though it can miss interesting reductions,
since it is way more efficient (from what I hear) than the fully general
approach, so should be able to handle code sequences longer than just a couple
of instructions.
Ciao, Duncan.
More information about the llvm-dev
mailing list