This is the mail archive of the
mailing list for the GCC project.
strange use of function_invariant_p (Was: Re: Followup for reg_equiv_invariant patch: Fix PR39871)
- 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 02:38:04 -0400
- Subject: strange use of function_invariant_p (Was: Re: Followup for reg_equiv_invariant patch: Fix PR39871)
- References: <4C16B0B4.firstname.lastname@example.org> <email@example.com> <4C1702DD.firstname.lastname@example.org> <email@example.com> <4C175C23.firstname.lastname@example.org> <4C1A9971.email@example.com>
Quoting Bernd Schmidt <firstname.lastname@example.org>:
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
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
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
30134 crux elimination_effects
30134 crux return;
When will this condition ever trigger? If this is not dead code, then
at least it is lacking a comment.