Re: [PATCH 2/13] D: The front-end (GDC) implementation.

[Jeff Law <law at redhat dot com>]

On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
> 
> For the actual code generation pass, that converts the front-end AST
> to GCC trees, most parts use a separate Visitor interfaces to do a
> certain kind of lowering, for instance, types.cc builds *_TYPE trees
> from AST Type's.  The Visitor class is part of the DMD front-end, and
> is defined in dfrontend/visitor.h.
> 
> There are also a few interfaces which have their headers in the DMD
> frontend, but are implemented here because they do something that
> requires knowledge of the GCC backend (d-target.cc), does something
> that may not be portable, or differ between D compilers
> (d-frontend.cc) or are a thin wrapper around something that is managed
> by GCC (d-diagnostic.cc).
> 
> Many high level operations result in generation of calls to D runtime
> library functions (runtime.def), all with require some kind of runtime
> type information (typeinfo.cc).  The compiler also generates functions
> for registering/deregistering compiled modules with the D runtime
> library (modules.cc).
> 
> As well as the D language having it's own built-in functions
> (intrinsics.cc), we also expose GCC builtins to D code via a
> `gcc.builtins' module (d-builtins.cc), and give special treatment to a
> number of UDAs that could be applied to functions (d-attribs.cc).
> 
> 
> That is roughly the high level jist of how things are currently organized.
> 
> Regards
> Iain
> 
> ---
> 
Presumably the types and interfaces which are capitalized in violation
of GNU standards are done so to interface the the DMD implementation?

Which implies the answer to a question in my prior message, namely that
the DMD implementation does get linked into GCC itself.  So I think we
need the SC to rule on whether or not that's allowed.

I'm not going to dive deep into this code -- it's essentially converting
between the different representations and is code that you'd be maintaining.

You probably want to review the #ifdefs you've got in here to make sure
they're not supposed to be checked via #if or runtime checks (there's
only a half-dozen or so):

+#ifdef STACK_GROWS_DOWNWARD
+#ifdef HAVE_LD_STATIC_DYNAMIC
+#ifdef HAVE_LD_STATIC_DYNAMIC
+#ifdef BIGGEST_FIELD_ALIGNMENT
+#ifdef ADJUST_FIELD_ALIGN
+#ifdef ENABLE_TREE_CHECKING

Joseph already commented on Target::critsecsize.

Jeff


Jeff