Recent changes to GDC.

[Artur Skawina]

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's not that "i want cross-module inlining" - in a language like D it's
practically required, for anything bigger than a single module. There are
even cases in runtime where "{return 1;}" functions are not inlined (eg the
malloc/mmap wrappers).

When i did the gcbits asms it was prompted by this profile:

37.62%  uint gc.gcx.Gcx.fullcollect(void*)
20.47%  uint gc.gcbits.GCBits.test(uint)
13.80%  uint gc.gcbits.GCBits.testSet(uint)
10.15%  pure nothrow @safe bool std.uni.isGraphical(dchar)
 3.33%  _D3std5array17__T8AppenderTAyaZ8Appender10__T3putTwZ3putMF
 2.78%  0x11025a        
 2.13%  _D3std6format65__T13formatElementTS3std5array17__T8Appende
 1.64%  _D3std6format56__T10formatCharTS3std5array17__T8AppenderTA
 1.37%  pure @safe uint std.utf.encode(ref char[4], dchar)
 0.88%  void* gc.gcx.GC.malloc(uint, uint, uint*)
 0.50%  pure nothrow @safe bool std.uni.binarySearch2(dchar, immutable(dchar[2][]))
 0.45%  void gc.gcbits.GCBits.set(uint)
 0.37%  void gc.gcbits.GCBits.clear(uint)
 0.34%  __divdi3

Clearly the garbage collector needs some love, but the 33%+ of the total
app runtime (!) spent in those two trivial functions makes judging any
GC improvements much harder. Even when inlined, the gcbits.* methods are
still the hottest parts of the whole app, and while in this case it's the
GC that needs fixing, that's not going to always be the case.

A hack that can often be used to get cross module inlining working is
adding a pair of parentheses - GDC will not throw away the function
(well, now template) bodies and will happily inline them. But that's not
really a good solution...

>>> * GDC's default calling convention has now been switched back to that of the default for the target platform.
>>
>> Hmm. You just invented a new ABI. "extern(D)" will mean different things to
>> different compilers on the same platform. Only makes sense if you're sure to
>> win the ABI war, and the other party to practically disappear.
> 
> I did not invent an ABI.  extern(D) is only defined for the x86
> platform - and it is no secret that only DMD adheres to it.

But what GDC emits for "extern(D)" is different both from what other D
compilers do (what does LDC do on x86, BTW?) *and* it's different from
the C/C++ convention...

>> This new ABI still isn't compatible with the default "C/C++" one, because of
>> name mangling. (could it be made, at least partially, C++ compatible?)
>> As you still cannot easily call D code from C, without the equivalent of
>> "extern(D)", why not default to a more sane calling conventions, such as
>> regparm on 32-bit x86?
> 
> The default calling convention is cdecl - this is directly ABI
> compatible with C and C++ code with the exception to name mangling
> requiring special treatment.
> 
> eg:
> 
> extern "C" int _Dmain(struct string args);

That one exception makes a difference - it's still not directly
callable from C/C++ w/o some kind of "extern(D)" declaration.
(the _Dmain identifier is not the best example, other functions
will not have similarly simple names...)
And, yes, in theory, it could be done, but do you really expect
C/C++ modules to directly use the demangled names?...

Things like:

pragma(attribute, ifunc("_D5ifunc6pick_fFZPFiZv")) void f(int i);

is about the only time i had to do it (and this is actually a bug -
ifunc should demangle the name).

BTW, is the GDC exception handling compatible with C++?


>> GCC made a mistake years ago to not mangle the names when using a nonstd
>> convention (eg by prepending '@' like some other compilers did) which
>> resulted in this feature being unusable, other than for application-internal
>> functions, as calling the wrong version will silently build and link, only to
>> blow up at runtime; you also cannot place both versions in a library etc.
>> Hence "fixing" this had to wait for a new architecture (x86_64) and whole
>> program optimizations/LTO, which can figure out automatically when it's safe
>> to switch to a more efficient convention.
>>
> 
> 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?


>>> The D_InlineAsm family of version identifiers are now turned off by default as we no longer pretend to follow DMD's calling convention. For those who want to turn on D_InlineAsm(_X86/_x86_64) there is a -fd-inline-asm compiler switch.
>>
>> Why is it a compiler option? Ie is it safe to turn it on (why optional then?)
>> or will it result in wrong code being generated (why have the option then?).
>> D_InlineAsm allowed things like the cpuid code to work, will every asm{} now
>> need to be rewritten, or could a safe subset of the "D" asms be reused?
>>
> 
> All Inline Asm code in Druntime and Phobos is written with the DMD
> calling convention in mind, so ie: when one of the naked functions in
> std.math pops the stack when returning a float, the caller won't clean
> this in GDC generated code.  Other than that, it works perfectly well
> (tm).

Ah, ok, thank you for clarifying that. It would then be possible to keep
D_InlineAsm working and only fail (or warn) when "naked" is used in "D" asm,
right?


>>> * GDC will emit the GNU_InlineAsm version identifier to tell user code that we support GNU Extended Inline Assembly.
>>
>> BTW, a identifier, which is set for *both* x86 and x86_64 would be good - because
>> of how D's version() works and the fact that on those platforms the asm code will
>> often be identical.
>>
>>> * All patches to GCC proper have now been removed, GDC can now build applications without relying on changes to the backend, with the exception of naked functions.
>>>
>>> * "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)?..

artur