llvm dev - Jul 2007 - [LLVMdev] not to break 'for' statement into basic blocks

Hello, Seung J. Lee
> LLVM optimization and other tools are really fantastic. 
> However I don't want LLVM breaks my 'for' statement in C code
into
> basic blocks during compiling. 
> I'm sure this sounds really strange but there is a reason for me.
LLVM is 'low-level'. It doesn't contain any special instruction for
loops at all.
> Furthermore, this assembly does not have the notion of
> 'br'instruction, phi-node and so on. Therefore, I have no choice
> without making 'for' in the assembly. 
Maybe you can look, how code operates on phi-nodes in C & MSIL backends.
> 1) First, I tried to re-unite basic blocks which llvm-gcc spits out to make
'for' again.
> But this is quite tricky. Generalizing it for the optimzed llvm bytecode is
not easy.
I'd say 'is not possible at all'.

In general, loop contain induction variable, which is being assigned
each iteration of loop. As LLVM IR is in SSA mode, there are only two
possibilities to operate on induction variable so:

1. Use phi node
2. Use memory (memory is never in SSA form)

So, if you don't want to deal with phi-node, you have to lower
everything to memory. 'reg2mem' pass is your friend in this case. This
will eliminate all phi nodes, but you have to resolve all branches.

However, I really don't see, how you can transform C code (in general)
to your target, because C *has* explicit goto statement. Maybe you can
split the whole CFG into "cycles" and "paths" and try to
"lower" them.
But this can be pretty complicated.

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Saturday 14 July 2007 17:23, Anton Korobeynikov wrote:
> > 1) First, I tried to re-unite basic blocks which llvm-gcc spits out to
> > make 'for' again. But this is quite tricky. Generalizing it
for the
> > optimzed llvm bytecode is not easy.
>
> I'd say 'is not possible at all'.
No, it certainly is possible.  One does this, for example, when constructing
a control dependence graph.  It can't be represented in llvm, so one needs
a higher-level abstraction.  A control dependence graph is one such 
abstraction.

Even llvm has a notion of "loops" that it extracts from the control
flow
graph.  Now, these are very low-level abstractions and probably won't work
for the purposes of this ISA.

And when you get difficult control behavior...
> However, I really don't see, how you can transform C code (in general)
> to your target, because C *has* explicit goto statement. Maybe you can
> split the whole CFG into "cycles" and "paths" and try
to "lower" them.
> But this can be pretty complicated.
Again, gotos can be eliminated with some program analysis and transformation.
See, for example, http://citeseer.ist.psu.edu/22521.html.

                                           -Dave