PR debug/60655, debug loc expressions

[Maciej W. Rozycki]

On Tue, 9 Sep 2014, Alan Modra wrote:

> This cures PR60655 on PowerPC by passing the horrible debug_loc
> expressions we have through simplify_rtx.  Not only do we get
> 	reg10 + &.LANCHOR0 + const(0x14f - &.LANCHOR0) and
> 	reg10 + &modulus + const(~&d_data),
> the two expressions that cause the PR due to (CONST (MINUS ..)) and
> (CONST (NOT ..)), but also things like
>        ~reg5 - reg31 + reg5 + reg10 + &modulus
> where "~reg5 + reg5" is an inefficient way to write "-1".
> 
> It turns out that merely passing these expression through simplify_rtx
> isn't enough.  Some tweaking is necessary to make (CONST (NOT ..)) and
> (CONST (MINUS ..)) recognised by simplify_plus_minus, and even after
> doing that, the two reg5 terms are not cancelled.
> 
> The reg5 case starts off with the simplify_plus_minus sorted ops array
> effectively containing the expression
> -reg31 + reg10 + reg5 + -reg5 + &modulus + -1
> 
> The first combination tried is &modulus + -1, which is rejected to
> prevent recursion.  The next combination tried is -reg5 + -1, which is
> simlified to ~reg5.  Well, that is a valid simplification, but the
> trouble is that this prevents "reg5 + -reg5" being simplified to 0.
> What's more, "&modulus + -1" is no more expensive than "&modulus",
> since they are both emitted as an address field with a symbol+addend
> relocation.  For that reason, I believe we should not consider
> combining a const_int with any other term after finding that it can be
> combined with a symbol_ref or other similar term.
> 
> Bootstrapped and regression tested powerpc64-linux and x86_64-linux.
> I measured before/after bootstrap times on x86_64-linux because I was
> concerned about the extra simplify_rtx calls, and was pleasantly
> surprised to see a 0.23% improvement in bootstrap time.  (Which of
> course is likely just noise.)  OK to apply?

 Thanks for your work on this issue, I have tested your change with my 
usual powerpc-gnu-linux multilibs with the old and new result for
gcc.c-torture/compile/pr60655-2.c noted on the right:

-mcpu=603e						FAIL -> PASS
-mcpu=603e -msoft-float					FAIL -> PASS
-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe	FAIL -> PASS
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe	FAIL -> PASS
-mcpu=7400 -maltivec -mabi=altivec			FAIL -> PASS
-mcpu=e6500 -maltivec -mabi=altivec			FAIL -> PASS
-mcpu=e5500 -m64					PASS -> PASS
-mcpu=e6500 -m64 -maltivec -mabi=altivec		PASS -> PASS

-- please note that the test case used to pass for 64-bit multilibs even 
before your fix so unless your powerpc64-linux configuration includes 
32-bit multilibs as well, it does not really provide suitable coverage.

 Once your fix has been put in place the old ARM hack made for 4.9, that 
my original proposal has been based on:

2014-04-10  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

	PR debug/60655
	* config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
	(arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's
	ameliorating the cases where it can be.

can I suppose be reverted too.

  Maciej