This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: strange use of function_invariant_p
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Joern Rennecke <amylaar at spamcop dot net>
- Cc: Jeff Law <law at redhat dot com>, gcc at gcc dot gnu dot org, rth at gcc dot gnu dot org
- Date: Fri, 18 Jun 2010 10:02:33 +0200
- Subject: Re: strange use of function_invariant_p
- References: <4C16B0B4.6080604@codesourcery.com> <20100614223547.dwf4izvnn4s0wgcc-nzlynne@webmail.spamcop.net> <4C1702DD.9010506@redhat.com> <20100615020004.7gsvdqoa8sg4skwo-nzlynne@webmail.spamcop.net> <4C175C23.3000501@codesourcery.com> <4C1A9971.5000502@codesourcery.com> <20100618023804.vw2t3vjbk8scsgko-nzlynne@webmail.spamcop.net>
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'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.
Bernd