Summary * Workaround the unwind issue for shrink-wrap * Verify Linaro tickets.
Details: 1. Debugging the failed cases for shrink-wrap. To workaround the unwind issue, update arm_expand_epilogue to generate return not simple_return when sp is changed.
2. Setup Linaro toolchain and verify 8 tickets: *Linaro gcc: lp:1036170: Function pointer dereferenced twice. It is ARM special bug which is confirmed in 4.6, 4.7 and FSF trunk only on ARM. lp:1048709: wrong assembler, out of range vldr instruction. Confirmed in Linaro 4.6. Can not reproduce it in 4.7 or FSF 4.6. lp:1014658: It is c++11 related issue in 4.6. lp:944572: It is a gcc general issue. lp:972503 and lp:1039401 can not be reproduced.
* Linaro binary toolchain: lp:1046718: confirmed and fixed it. lP:1049498: invalid
Plans: * Prepare Linaro binary toolchain 2012.09 release. * Performance test for shrink-wrap. * Follow-up the tickets.
Best regards! -Zhenqiang
On 17 September 2012 19:49, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
Summary
- Workaround the unwind issue for shrink-wrap
- Verify Linaro tickets.
Details:
- Debugging the failed cases for shrink-wrap. To workaround the
unwind issue, update arm_expand_epilogue to generate return not simple_return when sp is changed.
Hmm. An interesting case for shrinkwrap is:
int foo(void *p) { char big-on-stack-object[543234];
if (p == NULL) return -1;
lots-of-code-that-causes-spills-and calls() }
as shortcutting the prologue is where we get the saving. Does the prologue normally touch SP, or is this for alloca() style functions only?
- Setup Linaro toolchain and verify 8 tickets:
*Linaro gcc: lp:1036170: Function pointer dereferenced twice. It is ARM special bug which is confirmed in 4.6, 4.7 and FSF trunk only on ARM. lp:1048709: wrong assembler, out of range vldr instruction. Confirmed in Linaro 4.6. Can not reproduce it in 4.7 or FSF 4.6. lp:1014658: It is c++11 related issue in 4.6. lp:944572: It is a gcc general issue. lp:972503 and lp:1039401 can not be reproduced.
- Linaro binary toolchain:
lp:1046718: confirmed and fixed it. lP:1049498: invalid
Plans:
- Prepare Linaro binary toolchain 2012.09 release.
- Performance test for shrink-wrap.
- Follow-up the tickets.
Best regards! -Zhenqiang
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 18 September 2012 07:04, Michael Hope michael.hope@linaro.org wrote:
On 17 September 2012 19:49, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
Summary
- Workaround the unwind issue for shrink-wrap
- Verify Linaro tickets.
Details:
- Debugging the failed cases for shrink-wrap. To workaround the
unwind issue, update arm_expand_epilogue to generate return not simple_return when sp is changed.
Hmm. An interesting case for shrinkwrap is:
int foo(void *p) { char big-on-stack-object[543234];
if (p == NULL) return -1;
lots-of-code-that-causes-spills-and calls() }
as shortcutting the prologue is where we get the saving. Does the prologue normally touch SP, or is this for alloca() style functions only?
For spilling and alloca() style functions, prologue will touch SP.
For a local array, prologue will also touch SP if accessing the array element. My logs show, gcc will generate code like
sub sp, sp, #size of the array ... ldr r3, [sp, offset]
Thanks! -Zhenqiang
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Zhenqiang Chen