Re: Labeling of blocks and locals

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.

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:

> (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

[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

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