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