2014-11-15 15:49 GMT+00:00 Andrew Pinski <pins...@gmail.com>: >> My local modifications can be found in the gcc git at >> apinski/thunderx-cost. Note I reverted this patch so I can continue >> working. The testcase is compiling newlib. Let me try to get it >> again. >> I was configuring a combined build with: >> --disable-fixed-point --without-ppl --without-python --disable-werror >> --enable-plugins --enable-checking --disable-sim --with-newlib >> --disable-tls --with-cpu=thunderx --with-multilib-list=lp64,ilp32 >> --target=aarch64-thunderx-elf --enable-languages=c,c++ > > Attached is the preprocessed source. > cc1 strtol.i -mabi=ilp32 -O2 > is enough to reproduce the ICE.
thanks. I can reproduce this ICE under -mabi=ilp32 on your code base. and it's strange LR marked as alive while the final assembly don't have it. the reason of this is the following pattern define_insn "*tb<optab><mode>1" define_insn "*cb<optab><mode>1" always declare to clobber some register while they don't always use them in code generation, so sub-optimal code generated, some registers are wasted. you can see before my patch x19 is allocated for that clobber, thus there is an unnecessary save of x19 to stack, while after my patch, x30 is allocated for that clobber, so aarch64_can_eliminate invoked after this will think this function require frame pointer according to our ABI, so there are unncessary frame setup instruction. basically, it's not inconsistent between aarch64_require_frame_p and aarch64_can_eliminate. it's inconsistent between aarch64_can_eliminate invoked before assign_by_spills and after that. and my first impression is that the gcc_assert in lra-eliminate.c is to strong and need to be relaxed in some situation. > > Thanks, > Andrew >
