This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Quoting Bernd Schmidt <>:

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]