Hi!

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.

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.

BTW: The x86_64 ABI rewrite only rewrites structures passed by value, therefore there is no need to handle ref parameters.

Regards
Kai

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

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

On Monday, 11 February 2013 at 06:05:09 UTC, Kai Nacke wrote:
> I think I have a working solution now - I fixed PR 14779. :-)

That's of course the best kind of solution... ;)

David