This is the mail archive of the
mailing list for the GCC project.
Re: strange use of function_invariant_p
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- 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 05:41:59 -0400
- Subject: Re: strange use of function_invariant_p
- References: <4C16B0B4.email@example.com> <firstname.lastname@example.org> <4C1702DD.email@example.com> <firstname.lastname@example.org> <4C175C23.email@example.com> <4C1A9971.firstname.lastname@example.org> <email@example.com> <4C1B2819.firstname.lastname@example.org>
Quoting Bernd Schmidt <email@example.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 &&
30134 crux && reg_equiv_constant[regno]
47226 rth && ! function_invariant_p
30134 crux elimination_effects (reg_equiv_constant[regno],
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?