From: David Malcolm <dmalcolm@redhat.com>
To: Jeff Law <law@redhat.com>
Cc: gcc-patches@gcc.gnu.org, jit@gcc.gnu.org
Subject: Re: [PATCH 10/27] New file: gcc/jit/libgccjit.c
Date: Wed, 01 Jan 2014 00:00:00 -0000 [thread overview]
Message-ID: <1415120262.29411.125.camel@surprise> (raw)
In-Reply-To: <5457E65B.9050204@redhat.com>
On Mon, 2014-11-03 at 13:32 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > This file implements the entrypoints of the library's public API.
> >
> > It performs error-checking at this boundary, before calling into the
> > jit-recording.h internal API.
> >
> > gcc/jit/
> > * libgccjit.c: New.
> > ---
> > gcc/jit/libgccjit.c | 1506 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 1506 insertions(+)
> > create mode 100644 gcc/jit/libgccjit.c
> >
> > +
> > +#define IS_ASCII_ALPHA(CHAR) \
> > + ( \
> > + ((CHAR) >= 'a' && (CHAR) <='z') \
> > + || \
> > + ((CHAR) >= 'A' && (CHAR) <= 'Z') \
> > + )
> > +
> > +#define IS_ASCII_DIGIT(CHAR) \
> > + ((CHAR) >= '0' && (CHAR) <='9')
> > +
> > +#define IS_ASCII_ALNUM(CHAR) \
> > + (IS_ASCII_ALPHA (CHAR) || IS_ASCII_DIGIT (CHAR))
> Can't we rely on the C library to give us equivalents?
I've been burned in the past by the C library using locales, in
particular the two lowercase "i" variants in Turkish.
These macros are used by gcc_jit_context_new_function to enforce C's
naming restrictions, to avoid errors from the assembler. The comment I
put there was:
/* The assembler can only handle certain names, so for now, enforce
C's rules for identifiers upon the name.
Eventually we'll need some way to interact with e.g. C++ name mangling. */
Am I right in thinking that for the assembler we need to enforce the C
naming rules specifically on *ASCII*.
(clearly another comment is needed here).
> > +
> > +/* TODO: mark failure branches as unlikely? */
> > +
> Not likely worth the effort. And it'd be better to somehow mark
> jit_error such that anytime a path unconditionally calls jit_error, the
> whole path is considered unlikely.
(nods)
> I think it was Ball & Larus that had a predictor of this nature, I don't
> recall its effectiveness offhand. But I'd rather be marking the
> function than sprinlkling unlikely all over the actual codepaths.
Presumably by marking it with __attribute__((cold)) ? (with a suitable
macro in case we're not being compiled with a gcc that supports it).
I suspect doing so will be of more use in teaching me about gcc
internals and the effect on generated code that in measurable benefits
to said code in this case :)
> > +static bool
> > +compatible_types (gcc::jit::recording::type *ltype,
> > + gcc::jit::recording::type *rtype)
> All function definitions should have a block comment describing the
> function and its arguments. This comment applies throughout the code
> and needs to be addressed prior to commit. In fact I really can't even
> continue review of this code due to the lack of comments -- I rely
> heavily on them.
Sorry. I'll post a followup with comments added.
Many of the functions are public API entrypoints, where there's a
comment in the public header. Should I simply duplicate the comment
from there into the .c file, or put a comment like:
/* Public entrypoint. See description in libgccjit.h. */
for each of these? (perhaps with additional text giving implementation
notes?)
Thanks for all the reviews. Looks like this and patch 16 are now the
only non-approved parts of the kit (I didn't see a review of 16).
Dave
next prev parent reply other threads:[~2014-11-04 17:02 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 0:00 [PATCH 00/27] Merger of jit branch v3 David Malcolm
2014-01-01 0:00 ` [PATCH 22/27] Documentation: top-level index.rst David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 04/27] New file: gcc/jit/notes.txt David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 01/27] gcc: configure and Makefile changes needed by jit David Malcolm
2014-01-01 0:00 ` Thomas Schwinge
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 07/27] New file: gcc/jit/dummy-frontend.c David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 02/27] JIT-related changes outside of jit subdir David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 10/27] New file: gcc/jit/libgccjit.c David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm [this message]
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` [jit] Use ISALPHA and ISALNUM rather than writing our own David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 03/27] Add Sphinx to install.texi David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 17/27] New file: gcc/jit/libgccjit++.h David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 25/27] Documentation: add "internals" subdirectory David Malcolm
2014-01-01 0:00 ` [PATCH 20/27] Documentation: Makefile and conf.py David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 15/27] New file: gcc/jit/jit-playback.h David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 18/27] New file: gcc/jit/TODO.rst David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 08/27] New file: gcc/jit/libgccjit.h David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` [PATCH 13/27] New file: gcc/jit/jit-recording.c David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 11/27] New file: gcc/jit/jit-common.h David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 00/27] Merger of jit branch v3 Jeff Law
2014-01-01 0:00 ` [PATCH 12/27] New file: gcc/jit/jit-recording.h David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 0/3] Minor tweaks to jit David Malcolm
2014-01-01 0:00 ` [PATCH 1/3] New test cases David Malcolm
2014-01-01 0:00 ` [PATCH 0/3] Minor tweaks to jit Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` [PATCH 3/3] Add comments to various functions in libgccjit.h David Malcolm
2014-01-01 0:00 ` [PATCH 2/3] Documentation tweak David Malcolm
2014-01-01 0:00 ` [PATCH 09/27] New file: gcc/jit/libgccjit.map David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 23/27] Documentation: the "intro" subdirectory David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 05/27] New file: gcc/jit/config-lang.in David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 14/27] New files: gcc/jit/jit-builtins.{c|h} David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` David Malcolm
2014-01-01 0:00 ` [PATCH 16/27] New file: gcc/jit/jit-playback.c David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [jit] Drop the disabled debugging code within handle_locations David Malcolm
2014-01-01 0:00 ` [PATCH 24/27] Documentation: add "topics" subdirectory David Malcolm
2014-01-01 0:00 ` [PATCH 21/27] Documentation: the "examples" subdirectory David Malcolm
2014-01-01 0:00 ` Jeff Law
2014-01-01 0:00 ` [PATCH 06/27] New file: gcc/jit/Make-lang.in David Malcolm
2014-01-01 0:00 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1415120262.29411.125.camel@surprise \
--to=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jit@gcc.gnu.org \
--cc=law@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).