This is the mail archive of the gcc-patches@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: PATCH: [darwin] Always turn on FP_SAVE_INLINE at -O3


Yes you are both right, I accidentally attached an intermediate patch version to the email
I sent out. The final version of the patch will contain the definition (from Apple's version):


#define FP_SAVE_INLINE(FIRST_REG) \
(optimize >= 3 \
  || ((FIRST_REG) > 60 && (FIRST_REG) < 64)

*This* version will, as pointed out below, do something. In particular, on the mesa SPEC Fp
benchmark, we see roughly a 1% performance improvement.


The reason for adding the "((FIRST_REG) > 60" clause, as I understand it (it was done long
before I got here) was to reduce code size somewhat, while having a minimal impact on
performance.


I think I want to test the patch above a bit more, then re-submit it for approval. Sorry for
the confusion.


-- Caroline

On May 5, 2004, at 4:02 PM, Stan Shebs wrote:

Andrew Pinski wrote:


On May 5, 2004, at 18:47, Stan Shebs wrote:



In the interest of propagating rumors via this mailing list :-), what is the general order of magnitude of "small improvement" here?


There is no improvement for the FSF's compiler as it is already inlined
for every optimization level.

You're right, I was hallucinating and thinking of the FP_SAVE_INLINE in apple-ppc-branch, which asks to call the function if there are more than about four registers to save, while the mainline definition always inlines. Caroline, let's go back and see if we can use the same FP_SAVE_INLINE in both mainline and Apple branch.

Stan



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