WIP: enable sret for dynamic arrays

[JohanEngelen]

Work In Progress!

The goal is to enable dynarray sret for Win64 and other platforms that wish it.
Making a PR to have Travis check the code on other platforms.
All comments are welcome.

[kinke]

Oh yes, I'm already loving this LLVM_D_BuildFunctionFwdDecl() getting rid of more than 200 lines. :]

[kinke]

tf => rt

[redstar]

@JohanEngelen You should make the LLVM_D_BuildFunctionFwdDecl() part a separate PR. It is useful on its own.

[redstar]

@JohanEngelen Could you please write me an email? I am not sure if I have a valid mail address from you.

[JohanEngelen]

@redstar I've set my email to public on github.

[JohanEngelen]

@redstar :'( I thought C++11 is available generally (it apparently is on win64). But it isn't... I guess it is not possible to require C++11? (LLVM 3.6+ does require it I thought?)

[dnadlinger]

I do think we should look into transitioning to LLVM 3.5+ and C++11 soon. However, we can't do this without having a proper plan of attack first, lest we want to upset package maintainers and users.

[JohanEngelen]

Yeah, ok. I will rewrite things to work with C-arrays, like the LLVM functions do. (maybe faster too, preventing dyn allocs...)

[JohanEngelen]

OK, I got things to work with sret arrays now on Win64. Note that dyn arrays are not passed byref still. For that to work, more work is needed in defining the runtime functions, and also in the calling code. (the helperfunctions should be extended in functionality, and the calling code should be made less ABI aware).

[coveralls]

Changes Unknown when pulling 555b8ba on JohanEngelen:abi-sret-win64 into * on ldc-developers:master*.

[JohanEngelen]

trying to pick this up again.
First: refactor how we fwd declare druntime functions, and also how druntime calls are generated. What I remember is that that is somewhat of a mess.

[JohanEngelen]

closing PR, going to start from scratch.

[kinke]

Great news!

As a work-around, we could make Win64TargetAbi::passByVal() return true for all types later rewritten by ExplicitByvalRewrite. We would then need to take care of actually rewriting these (then byref) args when rewriting the function type...

I'll take care of that, so that you're free to ask gABI->passByVal() whether a type is passed in memory and the LL function parameter is a pointer - if that's needed at all. A clean solution would probably let gABI->rewriteFunctionType() rewrite the runtime function as every other function.