[LLVMdev] Predication before CodeGen

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


On 07/10/2007, Nikhil A. Patil <patil.nikhil at gmail.com> wrote:
> 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:

oops, I meant to say before "Initial SelectionDAG construction"

> 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



More information about the llvm-dev mailing list