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: PATCH: Darwin specific 1-liners (1)

>>>>> Stan Shebs writes:

Stan> I don't think you should fault Dale too much for being careful.
Stan> The usual situation is that somebody puts a patch into generic code,
Stan> and it crumbles performance everywhere except on the one platform
Stan> that was tested.  This particular patch is based on empirical results,
Stan> and given the vagaries of PowerPC family members, ABIs, etc, it's
Stan> often not the case that a win for one combination is a win for all.

Stan> If you or Geoff are willing to make the claim that this will win for
Stan> all cases, then we'll happily make the code generic, but we have
Stan> neither the equipment nor the time to do empirical measurements
Stan> across the range of PowerPC targets, and so it seems better to me
Stan> not to claim an improvement that we can't back up with numbers.

	I am not faulting Dale for being cautious.  I am saying that if
this patch is not ABI-specific, the submitter should explore the broader
benefit.  "darwin.h" does not seem like the right place for a performance
patch or a patch testing HARD_REGNO_RENAME_OK.

	I cannot find any documentation for the macro (which obviously is
*NOT* Dale's fault).  Dale did not include any background about what type
of code would try to use LR for a tablejump.  Furthermore, lists
CTR first in tablejump matchers, so it should be preferred over LR.

	All recent PowerPC processors have LR stacks, so avoiding LR for
anything except returning from calls is good.

	What type of unoptimal code generation is this trying to solve and
why is that Darwin-specific?  I would have expected a patch to rs6000.h
with some justification which then could have been changed to a darwin.h
patch if analysis/discussion showed that it only was useful for Darwin.


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