version statement problem in gdc

[John Colvin]

On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:
> If only that logic held water...
>
> GDC actually provided the implementation of iasm to LDC.  
> Reasons why it
> was yanked out.
> - one big ugly x86 special case.

Fair enough, although I see no reason why Ds iasm shouldn't be 
extended to support other architectures in the future.

> - depended on backend headers poisoned for use in the frontend.

when you say poisoned, I presume you mean by the license?

> - frontend should not know or care about what arch it is 
> targeting.

what about all the other arch specific version statements? e.g. 
version(ARM)

> - most iasm in druntime/phobos rely on dmd's non-standard 
> calling convention.
> - it has been argued in the past that gdc should not define 
> D_InlineAsm_X86 if it does not follow dmd's ABI.

Is it a feasible idea to automatically convert dmds inline asm to 
gcc's extended inline asm?


A bit of context: I've been updating the inline asm array ops 
code in druntime (e.g. a[] += b[];) and managing to outpace gdc's 
codegen by - in some cases - a factor of 5. I'm very surprised by 
this, but as far as I can tell I'm not making any mistakes with 
the benchmarking. This is with the latest gdc with gcc4.9 
snapshot (-O3 -frelease -fno-bounds-check), compared with the 
latest ldc and dmd.

If my work gets merged in to druntime*, it could leave a 
situation where gdc loses out.

*some preliminary work can be seen here, although I have made 
some significant changes I haven't pushed yet: 
https://github.com/D-Programming-Language/druntime/pull/471