ABI rewite limitation?

David Nadlinger see at klickverbot.at
Tue May 14 20:30:09 PDT 2013


Hi Kai,

sorry for responding so late.

On Monday, 4 February 2013 at 17:27:12 UTC, Kai Nacke wrote:
> I try to create a workaround for LLVM bug 14779. On PPC64 an 
> anonymous structure
> used as a parameter is not handled correctly. LDC passes arrays 
> as type { i64, i8* } and is directly affected by this bug.
>
> 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.

> However I faced some challenges:
>
> - 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.

If you can come up with a more coherent design, feel free to 
replace it.

David


More information about the digitalmars-d-ldc mailing list