* Labeling of blocks and locals @ 2015-01-01 0:00 Dibyendu Majumdar 2015-01-01 0:00 ` David Malcolm 0 siblings, 1 reply; 5+ messages in thread From: Dibyendu Majumdar @ 2015-01-01 0:00 UTC (permalink / raw) To: jit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Labeling of blocks and locals 2015-01-01 0:00 Labeling of blocks and locals Dibyendu Majumdar @ 2015-01-01 0:00 ` David Malcolm 2015-01-01 0:00 ` Dibyendu Majumdar 2015-01-01 0:00 ` Dibyendu Majumdar 0 siblings, 2 replies; 5+ messages in thread From: David Malcolm @ 2015-01-01 0:00 UTC (permalink / raw) To: Dibyendu Majumdar; +Cc: jit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Labeling of blocks and locals 2015-01-01 0:00 ` David Malcolm @ 2015-01-01 0:00 ` Dibyendu Majumdar 2015-01-01 0:00 ` David Malcolm 2015-01-01 0:00 ` Dibyendu Majumdar 1 sibling, 1 reply; 5+ messages in thread From: Dibyendu Majumdar @ 2015-01-01 0:00 UTC (permalink / raw) To: David Malcolm; +Cc: jit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Labeling of blocks and locals 2015-01-01 0:00 ` Dibyendu Majumdar @ 2015-01-01 0:00 ` David Malcolm 0 siblings, 0 replies; 5+ messages in thread From: David Malcolm @ 2015-01-01 0:00 UTC (permalink / raw) To: Dibyendu Majumdar; +Cc: jit 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Labeling of blocks and locals 2015-01-01 0:00 ` David Malcolm 2015-01-01 0:00 ` Dibyendu Majumdar @ 2015-01-01 0:00 ` Dibyendu Majumdar 1 sibling, 0 replies; 5+ messages in thread From: Dibyendu Majumdar @ 2015-01-01 0:00 UTC (permalink / raw) To: David Malcolm; +Cc: jit 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-06-15 20:09 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-01 0:00 Labeling of blocks and locals Dibyendu Majumdar 2015-01-01 0:00 ` David Malcolm 2015-01-01 0:00 ` Dibyendu Majumdar 2015-01-01 0:00 ` David Malcolm 2015-01-01 0:00 ` Dibyendu Majumdar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).