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]

Re: strange use of function_invariant_p

Quoting Bernd Schmidt <>:

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?

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