On 27 November 2013 18:58, Vladimir Makarov <vmaka...@redhat.com> wrote: > On 11/27/2013, 12:16 PM, Jeff Law wrote: >> >> On 11/27/13 03:18, Yvan Roux wrote: >>> >>> Ping >>> >>> On 18 November 2013 09:40, Yvan Roux <yvan.r...@linaro.org> wrote: >>>> >>>> Ping. >>>> >>>> On 7 November 2013 15:56, Yvan Roux <yvan.r...@linaro.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> this patch fixed an LRA cycling due to secondary reload (Thumb mode). >>>>> Notice that this patch is a prerequisite to turn on LRA by default on >>>>> ARM. Bootstrapped on a9 and a15 without any regression in the >>>>> testsuite as LRA is off by default and with the regression reported in >>>>> the thread bellow when LRA is on. >>>>> >>>>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00725.html >>>>> >>>>> Thanks, >>>>> Yvan >>>>> >>>>> 2013-11-07 Yvan Roux <yvan.r...@linaro.org> >>>>> >>>>> * config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): >>>>> Return NO_REGS >>>>> for LRA >> >> ? >> >> How can that be correct? >> >> The secondary reload macros/hooks define cases where additional registers >> are needed to reload certain forms of rtl. I doubt the use of LRA >> completely eliminates the need for secondary reloads. > > When I designed LRA I wanted to remove as many hooks as possible because I > thought insn constraints as major info source are enough. Unfortunately I > did not succeed fully with secondary reload hooks and macros. It is still > needed for some complicated cases but general rule to port LRA to a target > is to try to switch these hooks off. > > For example, LRA can generate a move of pseudos of classes for which > hardware has no real insn. After that looking on the move constraints, LRA > can generate more move insns and additional pseudos to generate moves (loads > or stores if additional pseudos got NO_REGS) which represent real hardware > insns. In complicated cases when these macros are still needed, LRA runs > into infinite loop of such move generation if the macros are not used. > > I might be return to a project to remove necessity of such hooks and > macros for LRA but I am not sure when. I guess I need to write a small > guidance too how to port LRA. > > Also I found that in many cases as here, the macros although working for > reload can confuse LRA (because of different reload pass and LRA > implementation approaches). So I guess the patch is ok although I can not > approve it as I am not an arm port maintainer.
Thanks for the clarification Vladimir, and BTW I just find the same cycling issue on iWMMXT. Yvan
