RFC: VTA alias set discrepancy

[Aldy Hernandez <aldyh at redhat dot com>]

Hi folks.

I am debugging a bunch of Fortran -fdebug-compare failures on the
testsuite, all of which stem from symbols ending up on different alias
set slots.  Notice the 2 versus 3 discrepancy below:

< (insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI ("i.0.1535")
[flags 0x2] <var_decl # i.0>) [2 i.0+0 S4 A32])
			      ^^^^
---
> (insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI ("i.0.1535")
> [flags 0x2] <var_decl # i.0>) [3 i.0+0 S4 A32])
				^^^^

What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set.  It matters not that we reset DECL_RTL
immediately after, we have already created a new alias set for first
time callers:

  /* Try harder to get a rtl.  If this symbol ends up not being emitted
     in the current CU, resolve_addr will remove the expression referencing
     it.  */
...
...
    {
      rtl = DECL_RTL (decl);
      /* Reset DECL_RTL back, as various parts of the compiler expects
	 DECL_RTL set meaning it is actually going to be output.  */
      SET_DECL_RTL (decl, NULL);

In the non debug path we don't call rtl_for_decl_location().  Instead,
make_decl_rtl gets called through varpool_finalize_decl much later.
However, we end up creating alias sets in a different order, and even if
things end up in their correct alias sets, the numbers may be off from
the debug and non-debug paths.

A simple way to fix this would be to remove alias set numbers from the
RTL dumps when doing -fdebug-compare.  I can think of all sorts of other
evil ways of forcing the sets to be created in the right order, but it
seems like bending over backwards for no good reason.

What do y'all suggest?

Aldy