llvm dev - Oct 2012 - [LLVMdev] ABI: how to let the backend know that an aggregate should be allocated on stack

Hi All,

I am trying to handle the Homogeneous Aggregate for ARM-VFP according to the
spec:
C.1.vfp If the argument is a VFP CPRC and there are sufficient consecutive VFP
registers of the appropriate type unallocated then the argument is allocated to
the lowest-numbered sequence of such registers.

C.2.vfp If the argument is a VFP CPRC then any VFP registers that are
unallocated are marked as unavailable. The NSAA is adjusted upwards until it is
correctly aligned for the argument and the argument is copied to the stack at
the adjusted NSAA. The NSAA is further incremented by the size of the argument.
The argument has now been allocated.

We currently expand the Homogeneous Aggregate in Clang, but that does not
conform to the standard when we have a few VFP registers available but not
enough.

In that case, the beginning members of HA will be allocated to VFP, and the rest
will go on stack.

To fix the problem, it will be great if we can let the backend know the HA will
be on stack and later VPF CPRCs will be on stack as well.
There are some discussions on this, at least from the comments in
TargetInfo.cpp:
// This assumption is optimistic, as there could be free registers available
// when we need to pass this argument in memory, and LLVM could try to pass
// the argument in the free register. This does not seem to happen currently,
// but this code would be much safer if we could mark the argument with
// 'onstack'. See PR12193.

I am just wondering whether it is necessary to add onstack flag and is there any
issue related to that?

Another option, suggested by Daniel, is to convert HA to a convenient similar
type the backend won't pass in registers.
I tried to pass a struct with vector types, but the backend will expand the
struct
See llvm::ComputeValueVTs
// Given a struct type, recursively traverse the elements.

I tried to use indirect in Clang, it does not work out as I wish.

Any suggestion on how to fix this is highly appreciated!

Thanks,
Manman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121023/6f5081e6/attachment.html>

On Tue, Oct 23, 2012 at 11:22 AM, manman ren <mren at apple.com>
wrote:
>
> Hi All,
>
> I am trying to handle the Homogeneous Aggregate for ARM-VFP according to
the
> spec:
>
> C.1.vfp If the argument is a VFP CPRC and there are sufficient consecutive
> VFP registers of the appropriate type unallocated then the argument is
> allocated to the lowest-numbered sequence of such registers.
>
> C.2.vfp If the argument is a VFP CPRC then any VFP registers that are
> unallocated are marked as unavailable. The NSAA is adjusted upwards until
it
> is correctly aligned for the argument and the argument is copied to the
> stack at the adjusted NSAA. The NSAA is further incremented by the size of
> the argument. The argument has now been allocated.
>
> We currently expand the Homogeneous Aggregate in Clang, but that does not
> conform to the standard when we have a few VFP registers available but not
> enough.
>
> In that case, the beginning members of HA will be allocated to VFP, and the
> rest will go on stack.
>
> To fix the problem, it will be great if we can let the backend know the HA
> will be on stack and later VPF CPRCs will be on stack as well.
> There are some discussions on this, at least from the comments in
> TargetInfo.cpp:
> // This assumption is optimistic, as there could be free registers
available
> // when we need to pass this argument in memory, and LLVM could try to pass
> // the argument in the free register. This does not seem to happen
> currently,
> // but this code would be much safer if we could mark the argument with
> // 'onstack'. See PR12193.
>
> I am just wondering whether it is necessary to add onstack flag and is
there
> any issue related to that?
>
> Another option, suggested by Daniel, is to convert HA to a convenient
> similar type the backend won't pass in registers.
> I tried to pass a struct with vector types, but the backend will expand the
> struct
> See llvm::ComputeValueVTs
> // Given a struct type, recursively traverse the elements.
>
> I tried to use indirect in Clang, it does not work out as I wish.
See MipsABIInfo::getPaddingType; a similar sort of approach should
work here.  (Granted, onstack would be more convenient, but it doesn't
exist at the moment.)

-Eli

In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in
llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers
would be counted up and if the HA didn't fit, it went byval instead.

I agree that we should unify this sort of logic in one place. I'm not sure
that onstack is the best interim step toward that. Does byval work here?

Alex

On Oct 23, 2012, at 11:22 AM, manman ren <mren at apple.com> wrote:
> 
> Hi All,
> 
> I am trying to handle the Homogeneous Aggregate for ARM-VFP according to
the spec:
> C.1.vfp If the argument is a VFP CPRC and there are sufficient consecutive
VFP registers of the appropriate type unallocated then the argument is allocated
to the lowest-numbered sequence of such registers.
> 
> C.2.vfp If the argument is a VFP CPRC then any VFP registers that are
unallocated are marked as unavailable. The NSAA is adjusted upwards until it is
correctly aligned for the argument and the argument is copied to the stack at
the adjusted NSAA. The NSAA is further incremented by the size of the argument.
The argument has now been allocated.
> 
> We currently expand the Homogeneous Aggregate in Clang, but that does not
conform to the standard when we have a few VFP registers available but not
enough.
> 
> In that case, the beginning members of HA will be allocated to VFP, and the
rest will go on stack.
> 
> To fix the problem, it will be great if we can let the backend know the HA
will be on stack and later VPF CPRCs will be on stack as well.
> There are some discussions on this, at least from the comments in
TargetInfo.cpp:
> // This assumption is optimistic, as there could be free registers
available
> // when we need to pass this argument in memory, and LLVM could try to pass
> // the argument in the free register. This does not seem to happen
currently,
> // but this code would be much safer if we could mark the argument with
> // 'onstack'. See PR12193.
> 
> I am just wondering whether it is necessary to add onstack flag and is
there any issue related to that?
> 
> Another option, suggested by Daniel, is to convert HA to a convenient
similar type the backend won't pass in registers.
> I tried to pass a struct with vector types, but the backend will expand the
struct
> See llvm::ComputeValueVTs
> // Given a struct type, recursively traverse the elements.
> 
> I tried to use indirect in Clang, it does not work out as I wish.
> 
> Any suggestion on how to fix this is highly appreciated!
> 
> Thanks,
> Manman
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121023/7ddd17ca/attachment.html>

Byval does not work for me, it will try to split the struct to fit into
available core registers and the rest on stack.

Sent from my iPhone

On Oct 23, 2012, at 5:01 PM, Alex Rosenberg <alexr at leftfield.org>
wrote:
> In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in
llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers
would be counted up and if the HA didn't fit, it went byval instead.
> 
> I agree that we should unify this sort of logic in one place. I'm not
sure that onstack is the best interim step toward that. Does byval work here?
> 
> Alex
> 
> On Oct 23, 2012, at 11:22 AM, manman ren <mren at apple.com> wrote:
> 
>> 
>> Hi All,
>> 
>> I am trying to handle the Homogeneous Aggregate for ARM-VFP according
to the spec:
>> C.1.vfp If the argument is a VFP CPRC and there are sufficient
consecutive VFP registers of the appropriate type unallocated then the argument
is allocated to the lowest-numbered sequence of such registers.
>> 
>> C.2.vfp If the argument is a VFP CPRC then any VFP registers that are
unallocated are marked as unavailable. The NSAA is adjusted upwards until it is
correctly aligned for the argument and the argument is copied to the stack at
the adjusted NSAA. The NSAA is further incremented by the size of the argument.
The argument has now been allocated.
>> 
>> We currently expand the Homogeneous Aggregate in Clang, but that does
not conform to the standard when we have a few VFP registers available but not
enough.
>> 
>> In that case, the beginning members of HA will be allocated to VFP, and
the rest will go on stack.
>> 
>> To fix the problem, it will be great if we can let the backend know the
HA will be on stack and later VPF CPRCs will be on stack as well.
>> There are some discussions on this, at least from the comments in
TargetInfo.cpp:
>> // This assumption is optimistic, as there could be free registers
available
>> // when we need to pass this argument in memory, and LLVM could try to
pass
>> // the argument in the free register. This does not seem to happen
currently,
>> // but this code would be much safer if we could mark the argument with
>> // 'onstack'. See PR12193.
>> 
>> I am just wondering whether it is necessary to add onstack flag and is
there any issue related to that?
>> 
>> Another option, suggested by Daniel, is to convert HA to a convenient
similar type the backend won't pass in registers.
>> I tried to pass a struct with vector types, but the backend will expand
the struct
>> See llvm::ComputeValueVTs
>> // Given a struct type, recursively traverse the elements.
>> 
>> I tried to use indirect in Clang, it does not work out as I wish.
>> 
>> Any suggestion on how to fix this is highly appreciated!
>> 
>> Thanks,
>> Manman
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121023/0c2d0959/attachment.html>

I will look into that, thanks

Sent from my iPhone

On Oct 23, 2012, at 4:39 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Tue, Oct 23, 2012 at 11:22 AM, manman ren <mren at apple.com>
wrote:
>> 
>> Hi All,
>> 
>> I am trying to handle the Homogeneous Aggregate for ARM-VFP according
to the
>> spec:
>> 
>> C.1.vfp If the argument is a VFP CPRC and there are sufficient
consecutive
>> VFP registers of the appropriate type unallocated then the argument is
>> allocated to the lowest-numbered sequence of such registers.
>> 
>> C.2.vfp If the argument is a VFP CPRC then any VFP registers that are
>> unallocated are marked as unavailable. The NSAA is adjusted upwards
until it
>> is correctly aligned for the argument and the argument is copied to the
>> stack at the adjusted NSAA. The NSAA is further incremented by the size
of
>> the argument. The argument has now been allocated.
>> 
>> We currently expand the Homogeneous Aggregate in Clang, but that does
not
>> conform to the standard when we have a few VFP registers available but
not
>> enough.
>> 
>> In that case, the beginning members of HA will be allocated to VFP, and
the
>> rest will go on stack.
>> 
>> To fix the problem, it will be great if we can let the backend know the
HA
>> will be on stack and later VPF CPRCs will be on stack as well.
>> There are some discussions on this, at least from the comments in
>> TargetInfo.cpp:
>> // This assumption is optimistic, as there could be free registers
available
>> // when we need to pass this argument in memory, and LLVM could try to
pass
>> // the argument in the free register. This does not seem to happen
>> currently,
>> // but this code would be much safer if we could mark the argument with
>> // 'onstack'. See PR12193.
>> 
>> I am just wondering whether it is necessary to add onstack flag and is
there
>> any issue related to that?
>> 
>> Another option, suggested by Daniel, is to convert HA to a convenient
>> similar type the backend won't pass in registers.
>> I tried to pass a struct with vector types, but the backend will expand
the
>> struct
>> See llvm::ComputeValueVTs
>> // Given a struct type, recursively traverse the elements.
>> 
>> I tried to use indirect in Clang, it does not work out as I wish.
> 
> See MipsABIInfo::getPaddingType; a similar sort of approach should
> work here.  (Granted, onstack would be more convenient, but it doesn't
> exist at the moment.)
> 
> -Eli