On Tue, Jan 24, 2012 at 01:45:40PM +1030, Alan Modra wrote:
> On Mon, Jan 23, 2012 at 07:29:18PM +0100, Jakub Jelinek wrote:
> > can hit it in some cases. The problem here is that var-tracking.c
> > (adjust_insn) isn't able to delegitimize it, because the UNSPEC_TOCREL
> > isn't added there to r2 register, but to a debug_expr (which only afterwards
> > is found to contain r2 value).
>
> Why don't we relax operand checks in rs6000_delegitimize_address?
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html did that as
> part of changing toc references. For mainline you'd just get rid of
>
> - && ((GET_CODE (XEXP (x, 0)) == REG
> - && (REGNO (XEXP (x, 0)) == TOC_REGISTER
> - || TARGET_MINIMAL_TOC
> - || TARGET_CMODEL != CMODEL_SMALL))
> - || (TARGET_CMODEL != CMODEL_SMALL
> - && GET_CODE (XEXP (x, 0)) == CONST
> - && GET_CODE (XEXP (XEXP (x, 0), 0)) == PLUS
> - && GET_CODE (XEXP (XEXP (XEXP (x, 0), 0), 0)) == REG
> - && REGNO (XEXP (XEXP (XEXP (x, 0), 0), 0)) == TOC_REGISTER
> - && GET_CODE (XEXP (XEXP (XEXP (x, 0), 0), 1)) == HIGH
> - && rtx_equal_p (XEXP (x, 1),
> - XEXP (XEXP (XEXP (XEXP (x, 0), 0), 1), 0)))))
If you relax the checking too much, don't you risk that something other than
the TOC register value is being added to the UNSPEC_TOCREL? Say, if you
have an 8byte object in .toc, and some loop body uses
((char *) &object)[1 + iv];
to access it, can't you end up with (r2 + 1), or (r2 + 1 + iv) being added
to UNSPEC_TOCREL? Certainly on i686 something like that happens and that
is why the delegitimization needs to be strict about the pic register
e.g. for UNSPEC_GOTOFF or UNSPEC_GOT.
I've checked in my patch already, I think it is desirable even if
delegitimization is somehow changed, it really models the linker
requirements that debug sections don't reference .toc section symbols
and this problem could pop up any time again with some other code.
And allows other targets to express their requirements too.
Jakub
