Labeling of blocks and locals

Labeling of blocks and locals

[Dibyendu Majumdar]

It seems that if a name is supplied to a block it is translated as a
label - but then if the same name is supplied to two blocks the labels
show up as the same.

In LLVM the block labels are automatically made unique - the user
supplied name is suffixed with a unique integer value. This is useful
as one can use meaningful labels without having to worry about making
the labels unique.

As it stands I would have to ensure unique label names before I could use them.

A similar question involves naming of locals. When I declare a local
and assign it a name - the name is not made unique. During code
generation whenever certain types of statements are processed, local
variables may be generated. These are given the same name - in LLVM
the names are automatically made unqiue, but I notice that in
libgccjit this is not so.

Of course I can work around this by creating unique label and local
names myself but that is an unnecessary pain.

Is it possible to consider changing this behaviour?


Thanks and Regards
Dibyendu

Re: Labeling of blocks and locals

[David Malcolm]

On Sun, 2015-06-14 at 20:21 +0100, Dibyendu Majumdar wrote:
> It seems that if a name is supplied to a block it is translated as a
> label - but then if the same name is supplied to two blocks the labels
> show up as the same.

They show up in dumps the same, which is going to be ambiguous to a
human reader, but I don't think it's a problem for the IR and the
compiler, I *think* it does it by identity, rather than be name, as it
were (not sure, but it's late here).

> In LLVM the block labels are automatically made unique - the user
> supplied name is suffixed with a unique integer value. This is useful
> as one can use meaningful labels without having to worry about making
> the labels unique.
> 
> As it stands I would have to ensure unique label names before I could use them.

FWIW in my compilers I've given them names based on the bytecode index,
so you might have e.g. "op0", "op0_true", "op0_false" etc for the 0th
bytecode, "op1" etc...   Although it's some extra work, it has an
advantage in that the names are more meaningful.  (BTW, the "const char
*" is copied, so you can build them up using snprintf into an on-stack
temporary buffer:
   char buf[16];
   snprintf(buf, sizeof(buf), "op%i", idx);
or somesuch).


> A similar question involves naming of locals. When I declare a local
> and assign it a name - the name is not made unique. During code
> generation whenever certain types of statements are processed, local
> variables may be generated. These are given the same name - in LLVM
> the names are automatically made unqiue, but I notice that in
> libgccjit this is not so.

Again, I'm not sure that this is a problem other than the ambiguity of
the dumps for the human reader; I *think* the IR/compiler treats two
locals created with multiple calls to gcc_jit_function_new_local as
different, even if they have the same name (it'd be a problem for
*globals* though).

> Of course I can work around this by creating unique label and local
> names myself but that is an unnecessary pain.
> 
> Is it possible to consider changing this behaviour?

Maybe.

Dave

Re: Labeling of blocks and locals

[Dibyendu Majumdar]

On 15 June 2015 at 04:41, David Malcolm <dmalcolm@redhat.com> wrote:
> On Sun, 2015-06-14 at 20:21 +0100, Dibyendu Majumdar wrote:
>> It seems that if a name is supplied to a block it is translated as a
>> label - but then if the same name is supplied to two blocks the labels
>> show up as the same.
>
> They show up in dumps the same, which is going to be ambiguous to a
> human reader, but I don't think it's a problem for the IR and the
> compiler, I *think* it does it by identity, rather than be name, as it
> were (not sure, but it's late here).
>
>> A similar question involves naming of locals. When I declare a local
>> and assign it a name - the name is not made unique. During code
>> generation whenever certain types of statements are processed, local
>> variables may be generated. These are given the same name - in LLVM
>> the names are automatically made unqiue, but I notice that in
>> libgccjit this is not so.
>
> Again, I'm not sure that this is a problem other than the ambiguity of
> the dumps for the human reader; I *think* the IR/compiler treats two
> locals created with multiple calls to gcc_jit_function_new_local as
> different, even if they have the same name (it'd be a problem for
> *globals* though).
>

I will ensure names are unique as otherwise they will be useless to
the human reader - but would be good if you confirmed whether name
plays any role other than being useful debugging information.

Thanks and Regards
Dibyendu

Re: Labeling of blocks and locals

[Dibyendu Majumdar]

On 15 June 2015 at 04:41, David Malcolm <dmalcolm@redhat.com> wrote:

> (BTW, the "const char
> *" is copied, so you can build them up using snprintf into an on-stack
> temporary buffer:
>    char buf[16];
>    snprintf(buf, sizeof(buf), "op%i", idx);
> or somesuch).
>

You anticipated my question!

Thanks

Re: Labeling of blocks and locals

[David Malcolm]

On Mon, 2015-06-15 at 20:21 +0100, Dibyendu Majumdar wrote:
> On 15 June 2015 at 04:41, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> > (BTW, the "const char
> > *" is copied, so you can build them up using snprintf into an on-stack
> > temporary buffer:
> >    char buf[16];
> >    snprintf(buf, sizeof(buf), "op%i", idx);
> > or somesuch).
> >
> 
> You anticipated my question!

...and fwiw it also applies to basically every place where the API takes
a const char *.  I'm working on a patch for the docs to clarify this.