<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div><br></div><div>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?<br><br>Alex</div><div><br>On Oct 23, 2012, at 11:22 AM, manman ren <<a href="mailto:mren@apple.com">mren@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><br></div><div>Hi All,</div><div><br></div><div>I am trying to handle the Homogeneous Aggregate for ARM-VFP according to the spec:</div><div>
<div class="page" title="Page 24">
<div class="layoutArea">
<div class="column"><p><span style="font-size: 10.000000pt; font-family: 'ArialMT'">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.
</span></p><p><span style="font-size: 10.000000pt; font-family: 'ArialMT'">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.</span></p><p><span style="font-size: 10.000000pt; font-family: 'ArialMT'">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.</span></p><div>In that case, the beginning members of HA will be allocated to VFP, and the rest will go on stack.</div><div><br></div><div>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.</div><div>There are some discussions on this, at least from the comments in TargetInfo.cpp:</div><div>// This assumption is optimistic, as there could be free registers available<br>// when we need to pass this argument in memory, and LLVM could try to pass<br>// the argument in the free register. This does not seem to happen currently,<br>// but this code would be much safer if we could mark the argument with<br>// 'onstack'. See PR12193.</div><div><br></div><div>I am just wondering whether it is necessary to add onstack flag and is there any issue related to that?</div><div><br></div><div>Another option, suggested by Daniel, is to convert HA to a convenient similar type the backend won't pass in registers.</div><div>I tried to pass a struct with vector types, but the backend will expand the struct</div><div>See llvm::ComputeValueVTs</div><div>// Given a struct type, recursively traverse the elements.</div><div><br></div><div>I tried to use indirect in Clang, it does not work out as I wish.</div><div><br></div><div>Any suggestion on how to fix this is highly appreciated!</div><div><br></div><div>Thanks,</div><div>Manman</div>
</div>
</div>
</div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>llvm-commits mailing list</span><br><span><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></span><br></div></blockquote></body></html>