Richard Henderson <address@hidden> writes:
On 02/24/2017 01:58 PM, David Gibson wrote:
On Fri, Feb 24, 2017 at 06:18:22AM +0530, Nikunj A Dadhania wrote:
Richard Henderson <address@hidden> writes:
On 02/24/2017 06:56 AM, Nikunj A Dadhania wrote:
Now get rid all the split out variables so, ca, ov. After this patch,
all the bits are stored in CPUPPCState::xer at appropriate places.
Signed-off-by: Nikunj A Dadhania <address@hidden>
---
target/ppc/cpu.c | 8 +---
target/ppc/cpu.h | 26 ++++++------
target/ppc/int_helper.c | 12 +++---
target/ppc/translate.c | 106 +++++++++++++++++++++++++-----------------------
4 files changed, 78 insertions(+), 74 deletions(-)
I do not think this is a good direction to take this.
Hmm, any particular reason?
Right, I suggested this, but based only a suspicion that the split
variables weren't worth the complexity. I'm happy to be corrected by
someone with better knowledge of TCG, but it'd be nice to know why.
Normally we're interested in minimizing the size of the generated code,
delaying computation until we can show it being used.
Now, ppc is a bit different from other targets (which might compute overflow
for any addition insn) in that it only computes overflow when someone asks for
it. Moreover, it's fairly rare for the addo/subo/nego instructions to
be used.
Therefore, I'm not 100% sure what the "best" solution is.
Agreed, with that logic, wont it be more efficient to move the OV/CA
updationg to respective callers, and when xer_read/write happens, its
just one tcg_ops.
However, I'd be surprised if the least amount of code places all of
the bits into their canonical location within XER.
Do note that when looking at this, the various methods by which the OV/SO bits
are copied to CR flags ought to be taken into account.
I lost you in the last two para, can you explain in detail?