For the lulz: ddmd vs libdparse lexer timings

David Nadlinger via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 6 19:59:13 PST 2015


On Tuesday, 6 January 2015 at 15:42:22 UTC, Daniel Murphy wrote:
> Yes, but __va_argsave is declared in the frontend, which is 
> unnecessary.  It was easy enough to make the glue layer reserve 
> the right number of bytes for varargs functions.

I agree. Walter said that he didn't manage to implement it back 
then, though, and I never looked at the glue layer.

> I made it a magic compiler type, and I'll make it automagically 
> pass by ref when used as a function argument on X86_64 posix.  
> That should do it.

Yes, that should indeed do it. I shied away from unilaterially 
making it a "magic" type in LDC to avoid unpleasant surprises for 
users. However, it is definitely the cleaner option imho.

> How does LDC currently handle it?  Does llvm have an easy way 
> to handle the implementation of va_* for you?

LLVM gives us va_start/…, and in theory also va_arg. However, 
there are two issues why we don't use the latter on Posix x86_64 
and rely on Walter's druntime implementation instead:

  1) For the template version of va_arg(), we'd need to redo the 
lowering of D types to the ABI types (passing in registers and so 
on, which is sadly not automatic in LLVM as its type system can't 
represent all C types). This could be implemented somewhat easily 
on top of argTypes, but because of 2) it was not really worth the 
effort.

  2) There is also a va_arg version that takes a TypeInfo at 
runtime. There doesn't really seem to be a way to implement this 
on top of what LLVM offers.

And as I said above, we currently have va_list as a pointer type 
for reasons of simplicity. Thus, we need to actually have our LDC 
va_start/va_copy intrinsics actually allocate memory for the 
register save area on the stack before forwarding to the LLVM 
ones. This is a huge hack, but just about seems to be enough to 
covervirtually all real-world use cases. In any case, I'm looking 
forward to cleaning this mess up once your DMD patches are in.

David


More information about the Digitalmars-d mailing list