Recent changes to GDC.

[Artur Skawina]

On 01/16/12 21:49, Iain Buclaw wrote:
> On 16 January 2012 19:14, Artur Skawina <art.08.09 at gmail.com> wrote:
>> On 01/16/12 17:43, Iain Buclaw wrote:
>>> On 16 January 2012 14:41, Artur Skawina <art.08.09 at gmail.com> wrote:
>>>> On 01/15/12 23:34, Iain Buclaw wrote:
>>>>> * Merged in the work Walter has done for __vector type support.  There are now newly available GCC builtins for vector operations via gcc.builtins module.
>>>>
>>>> Allowing !=128 bits wide types would be just a matter of removing the frontend
>>>> restrictions, right? (i didn't look at the latest commits, maybe you already did
>>>> that)
>>>> As the vector ops often will need to be wrapped, lack of cross module function
>>>> inlining is a problem.
>>>>
>>>
>>> If you want cross-module inlining, compile all sources in one command.
>>>
>>> gdc file1.d file2.d -o myapp
>>
>> Does this work for '-c' too? For building libs, like eg phobos?
>>
>> Hmm, '-fonly" seems like it could work, together with '-c' -- I have never
>> used that option, will have to try it later - but if it works, shouldn't it
>> be on by default (for '-[cS]' invocations)?
>>
> 
> It won't.  For inlining to work, the function body (that is available
> at compile-time in DMDFE AST) needs to be converted into GCC trees for
> the backend to inline.  -fonly, whilst it processes the semantic
> analysis on the other modules, does not generate any codegen for them.
>  For cross module inlining to properly work in the one-file-at-a-time
> compilation method, there needs to be an intermediate routine that
> says 'build this body now, but don't add the function to the global to
> output list'.

I guess treating the functions like C "extern inline"'s isn't possible?


>> BTW, is the GDC exception handling compatible with C++?
> 
> It's practically rewrite of the C++ exception routine in D. But don't
> quote me on it being directly compatible.

Hmm, i was looking for more incompatibilities, but i guess expecting to
directly throw/catch D exceptions from C++ (and v/v) is a bit too much. :)


>>> What makes you think changing the calling convention will turn off
>>> name mangling?
>>
>> My point is that modifying the ABI has a significant cost and can't easily
>> be undone. I don't see much gain from switching from one nonstd convention
>> to a different nonstd convention, which is /similar/ to the C one, but still
>> not directly accessible from C.
>> What does your change mean? Programs now use a worse calling convention (not
>> even one arg gets passed in a register), object files and libraries generated
>> by different D compilers are incompatible (by design, not just because of some
>> implementation quirk), worse, mixing libs produced by different toolchains may
>> seem to work, only to fail at runtime. Where's the gain?
>>
> 
> 1.  My point is that modifying the ABI has a significant cost and
> can't easily be undone. I don't see much gain from switching from one
> nonstd convention to a different nonstd convention, which is /similar/
> to the C one, but still not directly accessible from C.
> 
> A calling convention that is used by the target platform is better
> than a calling convention that is used by no one but yourself.  Also,
> I don't see how name mangling is part of the calling convention, but
> maybe that's just me (I am aware that name mangling is part of various
> Windows calling conventions, but not in *nix. :-)

It isn't, but if you can't (easily) call the "D" code from C/C++
it might as well be.
If you need proper annotations at every language border crossing,
what advantage does using the same calling convention give you?..


> 2. What does your change mean? Programs now use a worse calling
> convention (not even one arg gets passed in a register),
> 
> *cough* for x86 *cough*
> 
> I can't see how you can use this as an argument. Parameter passing
> hasn't changed for x86, only the way certain values are returned. So
> it is *still* as bad as it was *before* the change.

So gdc didn't implement the official (dlang.org) convention, and i was
fooled by LTO? :)


> 3. object files and libraries generated by different D compilers are
> incompatible (by design, not just because of some implementation
> quirk), worse, mixing libs produced by different toolchains may seem
> to work, only to fail at runtime. Where's the gain?
> 
> It has always been this way. I've never known people to frequently mix
> compilers when building code.

Shared libraries. Distributions, such as Ubuntu. Does every OS vendor
have to provide different packages for different D "stacks"? Every D
library will come in a DMD version, GDC version and a LDC version? Or
will just one compiler be picked, because the alternative isn't really
acceptable? Note the former also means packaging every application
using *any* D shared library (and i guess this can include phobos) N
times. Let's hope nobody else decides to make a D compiler. :)


>>>>> * "naked" has now been implemented now as a function attribute of the x86 platform.  It is applied to all naked functions, and implies noinline and noclone.
>>>>
>>>> I've never really understood the reason for "naked". Custom prologue and epilogue
>>>> could be useful sometimes, but turning the compiler into an assembler?... You can
>>>> already write "naked" asm functions in gcc - with asm()s outside of functions
>>>> plus some as(1) section push/pop magic, iirc.
>>>> Now you've removed the D builtin assembler, but decided to introduce "naked".
>>>> Is it really necessary? There are no back-compat concerns...
>>>> How does naked work will the various gcc features the modify prologue (profiling,
>>>> stack usage checking, forced stack aligment etc)?
>>>>
>>>
>>> I have not removed the D builtin assembler. I have just removed
>>> D_InlineAsm version identifers.  GDC's "naked" function support was
>>> originally a (pretty bad) hack in GCC.  It is now implemented cleanly
>>> as a function attribute, and does not affect the code generation of
>>> other frontends.
>>
>> I meant something like "practically removed the availability of D builtin
>> assembler by removing the guarding version identifiers", sorry.
>> But doesn't this mean that, right now, there are exactly zero users of this
>> feature (gcc naked functions)?..

> There is naked support for other architectures that have been accepted
> in GCC (arm, avr, m68k, mcore, rx, spu) - yes I had to  look them up.
> :-)

I meant "zero D users". :^)

And was wondering if introducing something D-related that nobody was
using made sense. I admit to *not* checking if some arch already had it. :)

artur