qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 26/28] target/ppc/mmu_common.c: Move BookE MMU functions t


From: Nicholas Piggin
Subject: Re: [PATCH v2 26/28] target/ppc/mmu_common.c: Move BookE MMU functions together
Date: Thu, 09 May 2024 15:57:15 +1000

On Thu May 9, 2024 at 9:33 AM AEST, BALATON Zoltan wrote:
> On Wed, 8 May 2024, Nicholas Piggin wrote:
> > On Tue May 7, 2024 at 10:31 PM AEST, BALATON Zoltan wrote:
> >> On Tue, 7 May 2024, Nicholas Piggin wrote:
> >>> What do you think about adding mmu-book3e.c instead?
> >>
> >> I have considered that but found that some functions have to be in the
> >> same file and declared static for the compiler to inline them otherwise I
> >> get worse performance. Maybe after these rearrangments it's now possible
> >> to move these out but as this series got a bit long already I dod not go
> >> through with that and left it for a follow up but I can give it a try.
> >
> > It would be nice.
>
> OK I've done that now as this also helps with some of the unint warnings 
> but I could not get rid of all work arounds completely.

Great, thank you.

> > What host machines are you using? I'm surprised inlining is causing
> > so much performance unless it is something older or in-order.
>
> Maybe it depends more on the compiler than host. I still use gcc 10 with 
> default -O2 level. Some people found that -O3 and LTO may help a bit but I 
> test with default QEMU settings as that may be what most use.

I was thinking just the cost of call/return should not be great.

It is definitely possible for inlining to allow compiler to make
more significant optimisations.

Since you're looking closely at performance and probably nobody
else has for a while I have no problem with it if you find it
faster, mind you.

Thanks,
Nick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]