llvm dev - Oct 2009 - [LLVMdev] PHI and Allocas

Hi,

I'm incrementing my toy compiler to account for variable mutations
around if/else blocks.

Reading the Kaleidoscope tutorial, I've learnt that I can substitute
the PHI node creation by allocas and retrieving the value later, if
needed. The Kaleidoscope example seems to account for one value only,
the result of:

Value *ThenV = Then->Codegen();
(...)
Value *ElseV = Else->Codegen();
(...)
PN->addIncoming(ThenV, ThenBB);
PN->addIncoming(ElseV, ElseBB);

But both Then and Else are expressions, so the Value returned is in
the form of a single variable.

ExprAST *Then = ParseExpression();
(...)
ExprAST *Else = ParseExpression();

In my toy language, I accept any number of statements inside a block.

Ignoring nested if statements, should I keep track of *each* variable
mutation inside the block, or is there some LLVM magic (as I'm getting
used to)?

A simple C example would be:

int a, b, c, d;
(...)
if (a > 10) {
  b = c = d = 10 * a;
} else {
  b = c = d = 10 / a;
}

As I'm always using alloca, the mem2reg pass seems to do the trick,
but I'm not sure it would in all cases. The tutorial states that it
works on all scalar values (I have no structs or arrays), so I believe
I'm safe.

Am I?

cheers,
--renato

On Thu, Oct 1, 2009 at 4:35 PM, Renato Golin <rengolin at systemcall.org>
wrote:
> Hi,
>
> I'm incrementing my toy compiler to account for variable mutations
> around if/else blocks.
>
> Reading the Kaleidoscope tutorial, I've learnt that I can substitute
> the PHI node creation by allocas and retrieving the value later, if
> needed. The Kaleidoscope example seems to account for one value only,
> the result of:
>
> Value *ThenV = Then->Codegen();
> (...)
> Value *ElseV = Else->Codegen();
> (...)
> PN->addIncoming(ThenV, ThenBB);
> PN->addIncoming(ElseV, ElseBB);
>
> But both Then and Else are expressions, so the Value returned is in
> the form of a single variable.
>
> ExprAST *Then = ParseExpression();
> (...)
> ExprAST *Else = ParseExpression();
>
> In my toy language, I accept any number of statements inside a block.
>
> Ignoring nested if statements, should I keep track of *each* variable
> mutation inside the block, or is there some LLVM magic (as I'm getting
> used to)?
>
> A simple C example would be:
>
> int a, b, c, d;
> (...)
> if (a > 10) {
>  b = c = d = 10 * a;
> } else {
>  b = c = d = 10 / a;
> }
>
> As I'm always using alloca, the mem2reg pass seems to do the trick,
> but I'm not sure it would in all cases. The tutorial states that it
> works on all scalar values (I have no structs or arrays), so I believe
> I'm safe.
>
> Am I?
I hope so, because I've been doing the same thing.  My local variables
are always bound to alloca's, and my test makefile just calls "opt
-std-compile-opts" after my compiler runs; so far it's been giving me
pretty good code as a result.

2009/10/1 Kenneth Uildriks <kennethuil at
gmail.com>:
> I hope so, because I've been doing the same thing.  My local variables
> are always bound to alloca's, and my test makefile just calls "opt
> -std-compile-opts" after my compiler runs; so far it's been giving
me
> pretty good code as a result.
Same here, but I'm not compiling any really complex code, so I thought
it was just beginner's luck.

Looks like it's another score for the "LLVM magic"! ;)

It might create problems for a potential debugger, but I'm not
planning to create one too soon.

cheers,
--renato

On Thu, Oct 1, 2009 at 2:35 PM, Renato Golin <rengolin at systemcall.org>
wrote:
> As I'm always using alloca, the mem2reg pass seems to do the trick,
> but I'm not sure it would in all cases. The tutorial states that it
> works on all scalar values (I have no structs or arrays), so I believe
> I'm safe.
>
> Am I?
Yes, you're safe; if the alloca is a scalar and you don't do anything
other than load and store to the alloca, mem2reg will eliminate the
alloca regardless of the control flow.  It's a fundamental property of
the algorithm to convert to SSA form; there's a comment in the source
code pointing to the paper in question if you're interested in the
theory.

-Eli