Re: Labeling of blocks and locals

[David Malcolm <dmalcolm@redhat.com>]

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