This is the mail archive of the gcc@gcc.gnu.org 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: An issue for the SC: horrible documentation quality of GCC


    This would not work for the copy propagation (as we need to remove the
    reference to the register in order to get dead code removed).

Can you define "copy propagation".  I'm not familiar with the term.

    Can you do some benchmarking on ROMP?  

No, it's a dead machine.  I was just giving that as an example of the sort
of problems you can get into by blindly replacing registers by constants.

It can be a tricky issue.  On the one hand, if you have a reg-reg SET with
at least one being a pseudo, if you replace the source with a constant, you
may have replaced a NOP with an insn that does something.  On the other,
doing that replacement may have eliminated the last use of another pseudo.

    I was worried about that when I was adding the local coprop pass (that
    don't introduce the problem just make it worse) and i did evaulation
    on SPARC (maybe MIPS, don't remember exactly) and the code produced
    was faster and shorter on the average so I concluded that this should
    be mostly safe.  When the constant is expensive, it usually means that
    it needs to be loaded to the register always and then the pattern
    should refuse immediate operand.

Clearly, but the issue isn't just when you need more than one instruction
to load the constant.  See above.  You run a risk of turning an insn that
will become a NOP into a real insn.

In some sense, the question is where is it better to have a NOP.  But in
the case I mentioned, where the NOP is in a conditional context, it's best
to have it there.

In other words, if we have

	if (condition)
	   a = exp1;
        else
	   a = exp2;

and we have a choice of putting the NOP before the "if" or making the
assignment from exp1 be a NOP, the latter is preferred since it eliminates
a junk.  Thus the heuristic is to have the NOP as *late* as possible.  But
I think the gcse.c code moves it as *early* as possible.


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