strange use of function_invariant_p (Was: Re: Followup for reg_equiv_invariant patch: Fix PR39871)

[Joern Rennecke <amylaar at spamcop dot net>]

Quoting Bernd Schmidt <bernds@codesourcery.com>:

> On 06/15/2010 12:55 PM, Bernd Schmidt wrote:
> > On 06/15/2010 08:00 AM, Joern Rennecke wrote:

[constants like (plus (REG:SI SP_REG) (symbol_ref foo))]

> > > function_invariant_p will accept them.
> >
> > I guess we can change that and not lose anything.
>
> This is what I committed after retesting on ARM (with -O2 -fpic included
> in TORTURE_OPTIONS).

You are not only rejecting invalid pic constants, you reject everything
that's not CONST_INT.  That could also include a
(const (unspec ...)) for some integer the target has to calculate after
register allocation / frame layout.

I was wondering if we'd use function_invariant_p in a context where allowing
CONST is important - e.g. could we have something like
(const (plus (const_int anchor) (const_int offset))) from  
LEGITIMIZE_RELOAD_ADDRESS.

I've stumbled over this piece of code in reload1.c:elimination_effects:

 30134       crux       else if (reg_renumber[regno] < 0 && reg_equiv_constant
 30134       crux              && reg_equiv_constant[regno]
 47226        rth              && ! function_invariant_p  
(reg_equiv_constant[regno]))
 30134       crux       elimination_effects  
(reg_equiv_constant[regno], mem_mode);
 30134       crux       return;

When will this condition ever trigger?  If this is not dead code, then
at least it is lacking a comment.