On 11 September 2017 at 17:42, Jeff Law <l...@redhat.com> wrote: > 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? >
Correct, I define my own code generation "passes" which handle the AST returned by DMD. > 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. > Target::critsecsize was dealt with in v2 of this patch. I think I can justify all #ifdef's being there, except for ENABLE_TREE_CHECKING which can be a runtime if (flag_checking). Iain.
