www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - ABI rewite limitation?

reply "Kai Nacke" <kai.nacke redstar.de> writes:
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
Feb 04 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Feb 10 2013
parent reply "Kai Nacke" <kai.nacke redstar.de> writes:
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
Feb 10 2013
parent "David Nadlinger" <see klickverbot.at> writes:
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
Feb 10 2013