ABI rewite limitation?

[Kai Nacke]

Hi David!

On Monday, 11 February 2013 at 00:32:17 UTC, David Nadlinger 
wrote:
> On Monday, 4 February 2013 at 17:27:12 UTC, Kai Nacke wrote:
>> My idea is to create a distinct type %ppc_pr14779_arraytype = 
>> type { i64, i8* } and use the ABI rewrite facility to 
>> substitute the type.
>
> This indeed seems like the lowest-impact way of dealing with 
> the situation. I guess you could also try modifying 
> IrTypeArray::get so that it returns a named type, but things 
> would probably break due to subtle assumptions being made in 
> random places.

I tried this and it doesn't work. E.g., code for static 
initializers breaks.

>> - ABIRewrite knows nothing about ref parameter
>>  The interface methods take the D type and D/LLVM values. More 
>> specialized informations like attributes of a parameter or the 
>> byref flag are missing.
>>  I worked around this by using 2 instances of my rewrite 
>> class: one for value parameters and one for ref parameters.
>>
>> - ABIRewrite.get()/.getL() is not called for ref parameters
>>  DtoDefineFunction simply excludes this case ( if (!refout...) 
>> )
>>  I solved this by adding another else to the if condition.
>>
>> Is this by design or just a deficiency of the interface?
>> My solution seems to work fine but I need to do more checking.
>
> Sorry, I can't help you there. The current design originated 
> from factoring out an existing chunk of ABI related code in 
> 2009, so it probably wasn't created with further extensibility 
> heavily in mind.

I tried several solutions. The current solution is really not so 
bad. If you pass a pointer to a structure as parameter then 
access to this parameter is always routed through DtoBitcast(). 
As a consequence you have to consider only pass by value 
arguments which the current implementation supports pretty well.

(It can't handle pointers to structures which are marked with 
byval. This also passes the structure by value.)

I think I have a working solution now - I fixed PR 14779. :-)

Kai