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.
