[ACTIVITY] Nov 8 - Nov 11
== GDB == * Worked on support for cross-platform core file generation. After some discussion on the mailing list it seems we've come to an agreement that the remote protocol ought to have two separate packets related to memory layout, one that describes the permanent, system-wide layout (for embedded systems) and one that describes the dynamic, per-process layout (for processes with memory-mapped files). The latter also ought to be integrated with the "info proc mappings" command, which should work with gdbserver too. I've been working on updating the patches accordingly. == GCC == * Patch review week. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 4th -11th November
Spun Linaro GCC 4.6 release tarball, uploaded it to Michael's server, and launched the testing. Continued work on constant reuse optimization. I've now eliminated some more false positives caused by inconsistent rtx_cost results. It turns out the pass also fixes up inefficient constants generated by arm_split_constants, which is nice. Set yet more spec benchmark runs going as part of the generic tuning investigation. Other: Half day Monday to recover from the weekend's travel. Half day on internal Mentor activities. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
trunk bootstrap failure on arm-linux-gnueabi
PR51068 appears to be a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 . I've kicked off a build on habitat.canonical.com with this patch applied to be sure that the build and test continues http://gcc.gnu.org/ml/gcc-patches/2011-11/txt00199.txt Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Agenda for tomorrow's call .
Hi, I've now put this at : https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-11-15 Are there any other topics that folks want to bring up ? The one thing worth thinking about ahead of time is if we want to bring ahead the call by an hour to allow Michael to join at a not so crazy hour for him. What do folks think of 9 a.m. Tuesdays / Wednesdays UTC ? cheers Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: How to fail an ARMv5T u-boot build when libgcc is ARMv7T2?
On 11/10/2011 05:44 PM, Loïc Minier wrote: > (Indeed, Ubuntu prepackaged Linaro-based cross-toolchains don't offer > multilib; that'd be hard in this context.) they do, but not the ones you want. ;-P the cross toolchain knows about arm soft float and arm hard float, but not about different processors. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Agenda for tomorrow's call .
Hi, > Are there any other topics that folks want to bring up ? There are some issues exposed while testing the register pressure estimation for SMS that I would to get some feedback on: As discussed off-line; one thing is related to the note_uses function which currently does not take element zero into account when dealing with ZERO_EXTRACT case (http://gcc.gnu.org/ml/gcc/2011-10/msg00419.html). I've bootstrap the solution of adding (*fun) (&XEXP (dest, 0), data); on PowerPC and I get a bootstrap failure (Internal error: abort in get_output_file_with_visibility, at gengtype.c:2093) . I debugged it to a point I know that the following expression causes it (applying this change for the 8799th time on this operation cause the failure); however I am not sure how to proceed with it as this operation does not look faulty; so I appropriate directions to precede. (zero_extract:DI (reg:DI 2829) (const_int 1 [0x1]) (const_int 3 [0x3])) Another issue is related to the regression I saw with SMS in libav's dsputil-ssd_int8_vs_int16_c. Consulting with Ayal regarding this it seemed that the regression was due to dependence between accumulations that can be avoided, more specifically we had the following case in vector code: vec1 = vec1 + ... ... vec1 = vec1+ ... ... vec1 = vec1+ ... ... vec1 = vec1+... to resolve this, I implemented a hack similar to MVE optimiation in the loop-unroller as follows: vec1 = vec1 + ... ... vec2 = vec2+ ... ... vec3 = vec3+ ... ... vec4 = vec4+... This gives ~4.5% improvements to the non-SMSed version. I was thinking of submitting this patch and I would appreciate thoughts about where to place it in the passes pipeline. Thanks, Revital ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Agenda for tomorrow's call .
Revital Eres writes: > Another issue is related to the regression I saw with SMS in libav's > dsputil-ssd_int8_vs_int16_c. > Consulting with Ayal regarding this it seemed that the > regression was due to dependence between accumulations that can be > avoided, more specifically we had the following case in vector code: > > vec1 = vec1 + ... > ... > vec1 = vec1+ ... > ... > vec1 = vec1+ ... > ... > vec1 = vec1+... > > to resolve this, I implemented a hack similar to MVE optimiation in > the loop-unroller as follows: > > vec1 = vec1 + ... > ... > vec2 = vec2+ ... > ... > vec3 = vec3+ ... > ... > vec4 = vec4+... While I agree that's a useful transformation, do you have a few more details about the SMS regression? I assume both the non-SMS and SMS loops use the: vec1 = vec1 + ... ... vec1 = vec1+ ... ... vec1 = vec1+ ... ... vec1 = vec1+... chain, so what makes the SMS version of it worse than the non-SMS version? Richard ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
