[Top][All Lists]

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

Re: [Qemu-ppc] [RFC PATCH 1/6] target/ppc: introduce get_fpr() and set_f

From: David Gibson
Subject: Re: [Qemu-ppc] [RFC PATCH 1/6] target/ppc: introduce get_fpr() and set_fpr() helpers for FP register access
Date: Tue, 11 Dec 2018 11:23:34 +1100
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Dec 10, 2018 at 12:25:26PM -0600, Richard Henderson wrote:
> On 12/9/18 11:17 PM, David Gibson wrote:
> > On Fri, Dec 07, 2018 at 08:56:30AM +0000, Mark Cave-Ayland wrote:
> >> These helpers allow us to move FP register values to/from the specified 
> >> TCGv_i64
> >> argument.
> >>
> >> To prevent FP helpers accessing the cpu_fpr array directly, add extra TCG
> >> temporaries as required.
> > 
> > It's not obvious to me why that's a desirable thing.  I'm assuming
> > it's somehow necessary for the stuff later in the series, but I think
> > we need a brief rationale here to explain why this isn't just adding
> > extra reg copies for the sake of it.
> Note that while this introduces extra opcodes, in many cases it does not 
> change
> the number of machine instructions that are generated.  Recall that accessing
> cpu_fpr[N] implies a load from env.  This change makes the load explicit.

I realised that a bit later in looking at the series.  I think a
paraphrasing of the above in the commit message would still be

> The change does currently prevent caching cpu_fpr[N] in a host register.  That
> can and will be fixed by optimizing on memory operations instead.  (There is a
> patch that has been outstanding for 13 months to do this.  I intend to finally
> get around to merging it during the 4.0 cycle.)
> r~

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: signature.asc
Description: PGP signature

reply via email to

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