Re: strange use of function_invariant_p

[Joern Rennecke <amylaar at spamcop dot net>]

Quoting Bernd Schmidt <bernds@codesourcery.com>:

> On 06/18/2010 08:38 AM, Joern Rennecke wrote:
>
> > 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.
>
> Examples?  I've never seen code that tries to offset the frame pointer
> by anything but a const_int.

I found in an as-yet unreleased port that I had to use an UNSPEC as a
placeholder for the return address; it is conceivable that you want
to express the location of return address as the sum of the stack pointer
and an as-yet unknown constant integer which you could express as
(CONST (UNSPEC ...)) .
Well, it doesn't look like it'll make a significant, if any, difference
on performance, I just wanted to point out that you committed a change
that is a bit different from what was discussed.

> > 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.
>
> I can't seem to find anything in the mailing list archives corresponding
> to revision 47226.  The testcase is gcc.dg/20011119-1.c.  I agree the
> code looks odd.

Should we put a gcc_unreachable there for now and a comment to remove the code
if it doesn't trigger for a while?