[LLVMdev] Predication before CodeGen

Nikhil A. Patil patil.nikhil at gmail.com
Sun Oct 7 00:51:46 PDT 2007


Hi,

I am  planning to generate code for a peculiar architecture with _no_ branch
instructions (!), but with predicated loads and stores to memory. This means
the architecture is not Turing complete, is going to waste a lot of
computation, and any input program that can hope to get compiled for this
architecture must have loops that can be fully unrolled, and all its
functions must get fully inlined.

Since I have no branches, I think I will need to predicate code before DAG
Selection. I was thinking of doing this:
1) Run an analysis on the LLVM bitcode that calculates the condition under
which an instruction will be "reached" -- this is straightforward since my
input program is not allowed to have cycles in the CFG.
2) Run a pass that requires the above analysis and uses it to:
   - merge all basic blocks in topological sort order (which exists, because
CFG is acyclic).
   - insert appropriate instructions to generate the predicates.
   - change all PHI-nodes into Select nodes.
   - predicate memory operations (well, at least the stores).

It is this final predication step that I am not sure how to handle. Since
LLVM does not have predicated load/store instructions, will I have to
upgrade the memory operations to a call or something that would then have to
be custom handled by the SelectionDAG mechanism?

Or should I just leave the load/stores alone, and somehow, later after the
machine instructions are created predicate them using this predicate
information? If so, how do I ensure that the dependency on the predicate
generating instructions is preserved (the predicate instructions are not
dce'd away)?

Or should I be trying to do the predication right before Legalize? If so,
I'll need to think about it a little more.

Thank you for your time :)
nikhil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071007/9f2a1407/attachment.html>


More information about the llvm-dev mailing list