Basic blocks, jump targets and locals

Basic blocks, jump targets and locals

[Dibyendu Majumdar]

Hi,

In LLVM the IRBuilder has the concept of a current block where
instructions are inserted. Reading the libgccjit docs I think that
there is no notion of current block - i.e. this needs to be maintained
by the caller - is that correct?

Can one create several blocks in advance - and set a block that is not
yet inserted into the function as the target for a jump? The scenario
is this: when compiling Lua bytecode I already know all the jump
targets. So I pre-create all the basic blocks that relate to the jump
targets up front - and as each jump is encountered I can easily set
the jump target to the right block. As and when I cross the bytecode
that is a jump target the block gets added to the function.

I hope above is clear - if not I can explain by an example.

Can I do something similar with libgccjit?

Finally - how are local variable related to blocks. In LLVM one has to
create the local vars in the entry block of the function. Is it the
same with libgccjit?

Thanks and Regards
Dibyendu

Re: Basic blocks, jump targets and locals

[David Malcolm]

On Thu, 2015-06-11 at 21:26 +0100, Dibyendu Majumdar wrote:
> Hi,
> 
> In LLVM the IRBuilder has the concept of a current block where
> instructions are inserted. Reading the libgccjit docs I think that
> there is no notion of current block - i.e. this needs to be maintained
> by the caller - is that correct?

Correct.

> Can one create several blocks in advance - and set a block that is not
> yet inserted into the function as the target for a jump? 

Yes.  See e.g.:
https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#populating-the-function
which does two passes:
(i) iterates through all of the bytecodes in a function, creating
gcc_jit_block instances for each one
(ii) iterates again, populating the gcc_jit_block instances with
statements

> The scenario
> is this: when compiling Lua bytecode I already know all the jump
> targets. So I pre-create all the basic blocks that relate to the jump
> targets up front - and as each jump is encountered I can easily set
> the jump target to the right block. As and when I cross the bytecode
> that is a jump target the block gets added to the function.

(nods)

> I hope above is clear - if not I can explain by an example.
> 
> Can I do something similar with libgccjit?

Hopefully the example above makes it clear.

> Finally - how are local variable related to blocks. In LLVM one has to
> create the local vars in the entry block of the function. Is it the
> same with libgccjit?

Local variables in libgccjit are local to a *function*; there's no
association between them and blocks.  Blocks in libgccjit relate to
control flow, not to scope.

Note that any initialization of a local variable has to be done
explicitly, by adding an assignment statement.  Typically that
assignment statement would be added to the initial block, as in the
example above (so I suppose that's an association of sorts between
locals and the entry block).

Hope this is clear
Dave

Re: Basic blocks, jump targets and locals

[Dibyendu Majumdar]

On 11 June 2015 at 21:31, David Malcolm <dmalcolm@redhat.com> wrote:
>> Can one create several blocks in advance - and set a block that is not
>> yet inserted into the function as the target for a jump?
>
> Yes.  See e.g.:
> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#populating-the-function
> which does two passes:
> (i) iterates through all of the bytecodes in a function, creating
> gcc_jit_block instances for each one
> (ii) iterates again, populating the gcc_jit_block instances with
> statements
>
>
>> Finally - how are local variable related to blocks. In LLVM one has to
>> create the local vars in the entry block of the function. Is it the
>> same with libgccjit?
>
> Local variables in libgccjit are local to a *function*; there's no
> association between them and blocks.  Blocks in libgccjit relate to
> control flow, not to scope.
>
> Note that any initialization of a local variable has to be done
> explicitly, by adding an assignment statement.  Typically that
> assignment statement would be added to the initial block, as in the
> example above (so I suppose that's an association of sorts between
> locals and the entry block).
>
> Hope this is clear


Thanks Dave - all very clear.

Re: Basic blocks, jump targets and locals

[Dibyendu Majumdar]

On 11 June 2015 at 21:31, David Malcolm <dmalcolm@redhat.com> wrote:
> Local variables in libgccjit are local to a *function*; there's no
> association between them and blocks.  Blocks in libgccjit relate to
> control flow, not to scope.
>
> Note that any initialization of a local variable has to be done
> explicitly, by adding an assignment statement.  Typically that
> assignment statement would be added to the initial block, as in the
> example above (so I suppose that's an association of sorts between
> locals and the entry block).
>

Can an assignment statement be added to a block that is already terminated?

Regards
Dibyendu

Re: Basic blocks, jump targets and locals

[David Malcolm]

On Sat, 2015-06-13 at 21:25 +0100, Dibyendu Majumdar wrote:
> On 11 June 2015 at 21:31, David Malcolm <dmalcolm@redhat.com> wrote:
> > Local variables in libgccjit are local to a *function*; there's no
> > association between them and blocks.  Blocks in libgccjit relate to
> > control flow, not to scope.
> >
> > Note that any initialization of a local variable has to be done
> > explicitly, by adding an assignment statement.  Typically that
> > assignment statement would be added to the initial block, as in the
> > example above (so I suppose that's an association of sorts between
> > locals and the entry block).
> >
> 
> Can an assignment statement be added to a block that is already terminated?

No; you'll get an error like:

adding to terminated block: entry (already terminated by: goto foo)

So you may want to wait until you've added all the initializations
before adding the jump from the entry block to the block for the first
bytecode.

Re: Basic blocks, jump targets and locals

[Dibyendu Majumdar]

On 15 June 2015 at 01:28, David Malcolm <dmalcolm@redhat.com> wrote:
> On Sat, 2015-06-13 at 21:25 +0100, Dibyendu Majumdar wrote:
>> On 11 June 2015 at 21:31, David Malcolm <dmalcolm@redhat.com> wrote:
>> > Local variables in libgccjit are local to a *function*; there's no
>> > association between them and blocks.  Blocks in libgccjit relate to
>> > control flow, not to scope.
>> >
>> > Note that any initialization of a local variable has to be done
>> > explicitly, by adding an assignment statement.  Typically that
>> > assignment statement would be added to the initial block, as in the
>> > example above (so I suppose that's an association of sorts between
>> > locals and the entry block).
>> >
>>
>> Can an assignment statement be added to a block that is already terminated?
>
> No; you'll get an error like:
>
> adding to terminated block: entry (already terminated by: goto foo)
>
> So you may want to wait until you've added all the initializations
> before adding the jump from the entry block to the block for the first
> bytecode.
>

I can do that, but maybe I don't need to? If the assignment occurs in
a subsequent block and is valid from control flow point of view then
it is correct - right?

Regards
Dibyendu

Re: Basic blocks, jump targets and locals

[David Malcolm]

On Thu, 2015-06-11 at 16:31 -0400, David Malcolm wrote:
> On Thu, 2015-06-11 at 21:26 +0100, Dibyendu Majumdar wrote:
> > Hi,
> > 
> > In LLVM the IRBuilder has the concept of a current block where
> > instructions are inserted. Reading the libgccjit docs I think that
> > there is no notion of current block - i.e. this needs to be maintained
> > by the caller - is that correct?
> 
> Correct.
> 
> > Can one create several blocks in advance - and set a block that is not
> > yet inserted into the function as the target for a jump? 
> 
> Yes.  See e.g.:
> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#populating-the-function
> which does two passes:
> (i) iterates through all of the bytecodes in a function, creating
> gcc_jit_block instances for each one
> (ii) iterates again, populating the gcc_jit_block instances with
> statements
> 
> > The scenario
> > is this: when compiling Lua bytecode I already know all the jump
> > targets. So I pre-create all the basic blocks that relate to the jump
> > targets up front - and as each jump is encountered I can easily set
> > the jump target to the right block. As and when I cross the bytecode
> > that is a jump target the block gets added to the function.
> 
> (nods)

BTW, you may want to use gcc_jit_block_add_comment:
https://gcc.gnu.org/onlinedocs/jit/topics/functions.html#gcc_jit_block_add_comment

which lets you add arbitrary comments as "statements" into the libgccjit
IR, so it shows up in the various debug dumps.  I've found this to be
hugely valuable when debugging compilation of bytecode into libgccjit.

> > I hope above is clear - if not I can explain by an example.
> > 
> > Can I do something similar with libgccjit?
> 
> Hopefully the example above makes it clear.
> 
> > Finally - how are local variable related to blocks. In LLVM one has to
> > create the local vars in the entry block of the function. Is it the
> > same with libgccjit?
> 
> Local variables in libgccjit are local to a *function*; there's no
> association between them and blocks.  Blocks in libgccjit relate to
> control flow, not to scope.
> 
> Note that any initialization of a local variable has to be done
> explicitly, by adding an assignment statement.  Typically that
> assignment statement would be added to the initial block, as in the
> example above (so I suppose that's an association of sorts between
> locals and the entry block).
> 
> Hope this is clear
> Dave
> 

Re: Basic blocks, jump targets and locals

[Dibyendu Majumdar]

On 11 June 2015 at 21:34, David Malcolm <dmalcolm@redhat.com> wrote:
> BTW, you may want to use gcc_jit_block_add_comment:
> https://gcc.gnu.org/onlinedocs/jit/topics/functions.html#gcc_jit_block_add_comment
>
> which lets you add arbitrary comments as "statements" into the libgccjit
> IR, so it shows up in the various debug dumps.  I've found this to be
> hugely valuable when debugging compilation of bytecode into libgccjit.

Cool. I will try that to annotate the blocks with the bytecode
instruction - that will be very useful for debugging.