Message ID | 5387708E.5020005@redhat.com |
---|---|
State | New |
Headers | show |
On Thu, May 29, 2014 at 06:38:22PM +0100, Vladimir Makarov wrote: > The following patch PR61325. The details can be found on > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325 > > The patch was bootstrapped and tested on x86/x86-64. > > Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk. > > 2014-05-29 Vladimir Makarov <vmakarov@redhat.com> > > PR rtl-optimization/61325 > * lra-constraints.c (process_address): Rename to > process_address_1. > (process_address): New function. > > 2014-05-29 Vladimir Makarov <vmakarov@redhat.com> > > PR rtl-optimization/61325 > * gcc.target/aarch64/pr61325.c: New. Hi Vlad, This patch appears to cause issues where the ARM backend can get stuck in a seemingly infinite loop. Compiling: ./gcc.c-torture/compile/unalign-1.c Directly With cc1 using command line: cc1 gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -O3 -mcpu=cortex-a15 -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4 Triggers the issue reproducibly for me across a few ARM configurations. Reverting this patch fixes the problem. Interrupting and asking gdb for a backtrace gives this: #1 0x005597cc in resize_reg_info() () at /home/jamgre01//gcc-clean/gcc/reginfo.c:912 #2 0x004b436c in get_reg_class(int) () at /home/jamgre01//gcc-clean/gcc/lra-int.h:400 #3 0x004b541c in in_class_p(rtx_def*, reg_class, reg_class*) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:265 #4 0x004b6314 in process_addr_reg(rtx_def**, rtx_def**, rtx_def**, reg_class) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:1176 #5 0x004b6aa0 in process_address_1(int, rtx_def**, rtx_def**) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:2829 #6 0x004bb150 in curr_insn_transform() () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:3001 #7 0x004bd884 in lra_constraints(bool) () at /home/jamgre01//gcc-clean/gcc/lra-constraints.c:4230 #8 0x004aca04 in lra(_IO_FILE*) () at /home/jamgre01//gcc-clean/gcc/lra.c:2333 For completeness, here is the -v output for one recent toolchain I've built. Using built-in specs. COLLECT_GCC=build/clean/install/bin/gcc COLLECT_LTO_WRAPPER=/home/jamgre01/build/clean/install/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: /home/jamgre01//gcc-clean/configure --with-cpu=cortex-a15.cortex-a7 --with-fpu=neon-vfpv4 --with-float=hard --prefix=/home/jamgre01/build//clean//install --enable-languages=c,c++,fortran Thread model: posix gcc version 4.10.0 20140603 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O3' '-v' '-mcpu=cortex-a15.cortex-a7' '-mfloat-abi=hard' '-mfpu=neon-vfpv4' '-mtls-dialect=gnu' /home/jamgre01/build/clean/install/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf -iprefix /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/ gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -quiet -dumpbase unalign-1.c -mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -mtls-dialect=gnu -auxbase unalign-1 -O3 -version -o /tmp/ccZj6iwS.s GNU C (GCC) version 4.10.0 20140603 (experimental) (armv7l-unknown-linux-gnueabihf) compiled by GNU C version 4.10.0 20140603 (experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/../../../../armv7l-unknown-linux-gnueabihf/include" ignoring duplicate directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include" ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf" ignoring duplicate directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include-fixed" ignoring nonexistent directory "/home/jamgre01/build/clean/install/bin/../lib/gcc/../../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/../../../../armv7l-unknown-linux-gnueabihf/include" #include "..." search starts here: #include <...> search starts here: /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include /home/jamgre01/build/clean/install/bin/../lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include-fixed /usr/local/include /home/jamgre01/build/clean/install/bin/../lib/gcc/../../include /usr/include/arm-linux-gnueabihf /usr/include End of search list. GNU C (GCC) version 4.10.0 20140603 (experimental) (armv7l-unknown-linux-gnueabihf) compiled by GNU C version 4.10.0 20140603 (experimental), GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Thanks, James
On 4 June 2014 00:02, James Greenhalgh <james.greenhalgh@arm.com> wrote: > On Thu, May 29, 2014 at 06:38:22PM +0100, Vladimir Makarov wrote: >> The following patch PR61325. The details can be found on >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325 >> >> The patch was bootstrapped and tested on x86/x86-64. >> >> Committed as rev. 211060 to gcc-4.9 branch and as rev.211061 to trunk. >> >> 2014-05-29 Vladimir Makarov <vmakarov@redhat.com> >> >> PR rtl-optimization/61325 >> * lra-constraints.c (process_address): Rename to >> process_address_1. >> (process_address): New function. >> >> 2014-05-29 Vladimir Makarov <vmakarov@redhat.com> >> >> PR rtl-optimization/61325 >> * gcc.target/aarch64/pr61325.c: New. > > Hi Vlad, > > This patch appears to cause issues where the ARM backend can get stuck in a > seemingly infinite loop. > > Compiling: > > ./gcc.c-torture/compile/unalign-1.c > > Directly With cc1 using command line: > > cc1 gcc-clean/gcc/testsuite/gcc.c-torture/compile/unalign-1.c -O3 -mcpu=cortex-a15 -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4 > > Triggers the issue reproducibly for me across a few ARM configurations. > Hello, On my side, I can see a huge increase in memory use (up to at least 350GB in make check) by GCC since this commit. (and the Compute Farm admins have started to kill my jobs because they consume too much memory ;-) I can see this on several ARM and AArch64 configurations, but not on armeb, aarch64-bare and arm* when restricting to armv5t. Christophe.
Index: lra-constraints.c =================================================================== --- lra-constraints.c (revision 210973) +++ lra-constraints.c (working copy) @@ -2784,9 +2784,14 @@ Add reloads to the lists *BEFORE and *AFTER. We might need to add reloads to *AFTER because of inc/dec, {pre, post} modify in the - address. Return true for any RTL change. */ + address. Return true for any RTL change. + + The function is a helper function which does not produce all + transformations which can be necessary. It does just basic steps. + To do all necessary transformations use function + process_address. */ static bool -process_address (int nop, rtx *before, rtx *after) +process_address_1 (int nop, rtx *before, rtx *after) { struct address_info ad; rtx new_reg; @@ -2986,6 +2991,18 @@ return true; } +/* Do address reloads until it is necessary. Use process_address_1 as + a helper function. Return true for any RTL changes. */ +static bool +process_address (int nop, rtx *before, rtx *after) +{ + bool res = false; + + while (process_address_1 (nop, before, after)) + res = true; + return res; +} + /* Emit insns to reload VALUE into a new register. VALUE is an auto-increment or auto-decrement RTX whose operand is a register or memory location; so reloading involves incrementing that location. @@ -3270,7 +3287,7 @@ change_p = true; lra_update_dup (curr_id, i); } - + if (change_p) /* If we've changed the instruction then any alternative that we chose previously may no longer be valid. */ Index: testsuite/gcc.target/aarch64/pr61325.c =================================================================== --- testsuite/gcc.target/aarch64/pr61325.c (revision 0) +++ testsuite/gcc.target/aarch64/pr61325.c (working copy) @@ -0,0 +1,19 @@ +/* { dg-do compile } */ +/* { dg-options "-O2" } */ +typedef unsigned int wchar_t; +typedef long unsigned int size_t; + +size_t +wcstombs(char *s , const wchar_t *pwcs , size_t n) +{ + int count = 0; + + if (n != 0) { + do { + if ((*s++ = (char) *pwcs++) == 0) + break; + count++; + } while (--n != 0); + } + return count; +}