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

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

[Iain Buclaw]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

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

---

[-- Attachment #2: 02-d-frontend-gdc.patch.xz --]
[-- Type: application/x-xz, Size: 124216 bytes --]

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

[Joseph Myers]

As I read it, the front end has functions with names such as error, but no 
useful i18n will actually occur because the functions in d-diagnostic.cc 
format the messages with xvasprintf before passing to the common 
diagnostic code.

But will exgettext nevertheless extract messages from the dfrontend code, 
if the functions happen to have string arguments in the same position as 
the generic diagnostic functions do?  If so, I think that should be 
disabled, to avoid putting a lot of messages in gcc.pot that won't 
actually be translated.  (If actual i18n support is desired, it should be 
shared with other users of the front end, which would mean using dgettext 
to extract translations in a different domain from the default GCC one, 
and so the messages shouldn't go in gcc.pot anyway.)

In d-target.cc you have code like:

+  else if (global.params.isLinux)
+    {
+      /* sizeof(pthread_mutex_t) for Linux.  */
+      if (global.params.is64bit)
+       return global.params.isLP64 ? 40 : 32;
+      else
+       return global.params.isLP64 ? 40 : 24;
+    }

which feels like it belongs in the config/ configuration for each target 
(as a target hook returning the required information), not in the D front 
end code.  I'm not clear what global.params.is64bit is meant to mean; it 
looks like "this is x86_64, possibly x32" in this patch.  These values 
aren't correct in general anyway; on AArch64, glibc has pthread_mutex_t of 
size 48 for LP64 and 32 for ILP32; on HPPA (only ILP32 supported for 
Linux) it's 48.

You have two new target macros TARGET_CPU_D_BUILTINS and 
TARGET_OS_D_BUILTINS.  You're missing any documentation for them in 
tm.texi.in.  And we prefer target hooks to macros.  So please try to 
convert them to (documented) target hooks.  (See c-family/c-target.def, 
and c_target_objs etc., for how there can be hooks that are specific to 
particular front ends.  See the comment in config/default-c.c regarding 
how to deal with a mixture of OS-dependent and architecture-dependent 
hooks.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Iain Buclaw]

On 13 June 2017 at 19:29, Joseph Myers <joseph@codesourcery.com> wrote:
> As I read it, the front end has functions with names such as error, but no
> useful i18n will actually occur because the functions in d-diagnostic.cc
> format the messages with xvasprintf before passing to the common
> diagnostic code.
>

That could be changed I guess to interact with
diagnostic_report_diagnostic() directly, rather than just being a high
level wrapper around gcc error_at()/warning_at().

> But will exgettext nevertheless extract messages from the dfrontend code,
> if the functions happen to have string arguments in the same position as
> the generic diagnostic functions do?  If so, I think that should be
> disabled, to avoid putting a lot of messages in gcc.pot that won't
> actually be translated.  (If actual i18n support is desired, it should be
> shared with other users of the front end, which would mean using dgettext
> to extract translations in a different domain from the default GCC one,
> and so the messages shouldn't go in gcc.pot anyway.)
>

I would say I'm open to i18n, however upstream D probably wouldn't be.
However as it is my intention to eventually switch the dfrontend
sources to D, exgettext extracting messages would cease to be a
problem.

> In d-target.cc you have code like:
>
> +  else if (global.params.isLinux)
> +    {
> +      /* sizeof(pthread_mutex_t) for Linux.  */
> +      if (global.params.is64bit)
> +       return global.params.isLP64 ? 40 : 32;
> +      else
> +       return global.params.isLP64 ? 40 : 24;
> +    }
>
> which feels like it belongs in the config/ configuration for each target
> (as a target hook returning the required information), not in the D front
> end code.  I'm not clear what global.params.is64bit is meant to mean; it
> looks like "this is x86_64, possibly x32" in this patch.  These values
> aren't correct in general anyway; on AArch64, glibc has pthread_mutex_t of
> size 48 for LP64 and 32 for ILP32; on HPPA (only ILP32 supported for
> Linux) it's 48.
>

That is something that I have been meaning to handle better.  I was
originally thinking something along the lines of it being determined
at configure time.  Then again, it's only use is for the dfrontend to
generate a lowering of synchronized statements that looks like:

    static byte[<critsecsize>] critsec;
    _d_criticalenter(critsec.ptr);
    try { ... }
    finally {
        _d_criticalexit(critsec.ptr);
    }

Returning a size that is large enough for all would work also in the worst case.


There are a number of fields in global.params that I would prefer
removed from the shared frontend.  I when through them all with a
co-collaborator on the core dlang team during Dconf, but I wouldn't
hold my breath for it to happen.


> You have two new target macros TARGET_CPU_D_BUILTINS and
> TARGET_OS_D_BUILTINS.  You're missing any documentation for them in
> tm.texi.in.  And we prefer target hooks to macros.  So please try to
> convert them to (documented) target hooks.  (See c-family/c-target.def,
> and c_target_objs etc., for how there can be hooks that are specific to
> particular front ends.  See the comment in config/default-c.c regarding
> how to deal with a mixture of OS-dependent and architecture-dependent
> hooks.)
>

OK, thanks for the suggestion!

Iain.

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

[Joseph Myers]

On Wed, 14 Jun 2017, Iain Buclaw wrote:

> > But will exgettext nevertheless extract messages from the dfrontend code,
> > if the functions happen to have string arguments in the same position as
> > the generic diagnostic functions do?  If so, I think that should be
> > disabled, to avoid putting a lot of messages in gcc.pot that won't
> > actually be translated.  (If actual i18n support is desired, it should be
> > shared with other users of the front end, which would mean using dgettext
> > to extract translations in a different domain from the default GCC one,
> > and so the messages shouldn't go in gcc.pot anyway.)
> >
> 
> I would say I'm open to i18n, however upstream D probably wouldn't be.
> However as it is my intention to eventually switch the dfrontend
> sources to D, exgettext extracting messages would cease to be a
> problem.

Well, until then you'd need to prevent exgettext from extracting the 
messages.

> That is something that I have been meaning to handle better.  I was
> originally thinking something along the lines of it being determined
> at configure time.  Then again, it's only use is for the dfrontend to
> generate a lowering of synchronized statements that looks like:

You can't readily determine this at configure time.  The only target libc 
properties that can be determined at configure time are those you can 
determine by examining the text of headers, since you don't have a 
compiler for the target at that point (gcc/ configure only tests compilers 
for the host and build systems), and this property is multilib-specific.  
I think a target hook is the right thing here.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Iain Buclaw]

On 14 June 2017 at 00:41, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 13 June 2017 at 19:29, Joseph Myers <joseph@codesourcery.com> wrote:
>> You have two new target macros TARGET_CPU_D_BUILTINS and
>> TARGET_OS_D_BUILTINS.  You're missing any documentation for them in
>> tm.texi.in.  And we prefer target hooks to macros.  So please try to
>> convert them to (documented) target hooks.  (See c-family/c-target.def,
>> and c_target_objs etc., for how there can be hooks that are specific to
>> particular front ends.  See the comment in config/default-c.c regarding
>> how to deal with a mixture of OS-dependent and architecture-dependent
>> hooks.)
>>
>
> OK, thanks for the suggestion!
>

Just to make sure I understand the structure correct.  There are a a
lot of files that would be involved.

- d/d-target.def: Define the hooks.
- d/d-target.h: Data definitions, extern gcc_targetdm;
- d/d-target-def.h: Default initializers (if applicable?)
- config.gcc: Add d_target_objs, assign platform and cpu files to it
as necessary.
- config/cpu/cpu-d.c: For each CPU that needs it, new file.  Here
would go CPU-related versions.
- config/os-d.c: For each OS that needs it, new file.  Here would go
OS and CRuntime versions, and other information like
sizeof(pthread_mutex_t).
- config/default-d.c: Define targetdm.
- config/glibc-d.c (others): Replaces default-d.c.
- config/t-glibc (others): Add build rules for above source file.
- Makefile.in: Add genhooks for d-target-hooks-def.h, build rule for default-d.c

I think that covers everything.

Regards
Iain

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

[Joseph Myers]

On Wed, 14 Jun 2017, Iain Buclaw wrote:

> Just to make sure I understand the structure correct.  There are a a
> lot of files that would be involved.
> 
> - d/d-target.def: Define the hooks.
> - d/d-target.h: Data definitions, extern gcc_targetdm;
> - d/d-target-def.h: Default initializers (if applicable?)
> - config.gcc: Add d_target_objs, assign platform and cpu files to it
> as necessary.
> - config/cpu/cpu-d.c: For each CPU that needs it, new file.  Here
> would go CPU-related versions.
> - config/os-d.c: For each OS that needs it, new file.  Here would go
> OS and CRuntime versions, and other information like
> sizeof(pthread_mutex_t).
> - config/default-d.c: Define targetdm.
> - config/glibc-d.c (others): Replaces default-d.c.
> - config/t-glibc (others): Add build rules for above source file.
> - Makefile.in: Add genhooks for d-target-hooks-def.h, build rule for default-d.c
> 
> I think that covers everything.

That seems about right - subject to the issue of how architecture-specific 
configuration is visible to the definition of targetdm if that definition 
is in an OS-specific file, without ending up with a target macro in tm.h 
that's visible everywhere (see the suggestion in config/default-c.c of 
having a tm_c.h for such definitions, so tm_d.h in this case).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Jeff Law]

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

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

[Iain Buclaw]

On 11 September 2017 at 17:42, Jeff Law <law@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.