On Thu, May 09, 2019 at 10:33:24AM +1000, Anton Blanchard wrote: > Hi Mark, > > > Following on from this I've just gone through the load/store > > operations once again and spotted two things: > > > > > > 1) VSX_LOAD_SCALAR_DS has an extra get_cpu_vsrh() which can be removed > > > > diff --git a/target/ppc/translate/vsx-impl.inc.c > > b/target/ppc/translate/vsx-impl.inc.c index 11d9b75d01..004ea56c4f > > 100644 --- a/target/ppc/translate/vsx-impl.inc.c > > +++ b/target/ppc/translate/vsx-impl.inc.c > > @@ -329,7 +329,6 @@ static void gen_##name(DisasContext > > *ctx) \ > > return; > > \ } \ xth > > = tcg_temp_new_i64(); \ > > - get_cpu_vsrh(xth, rD(ctx->opcode) + 32); \ > > gen_set_access_type(ctx, ACCESS_INT); \ > > EA = tcg_temp_new(); \ > > gen_addr_imm_index(ctx, EA, 0x03); \ > > Looks good. I also noticed we had two stores that needed to be fixed: > > VSX_LOAD_SCALAR_DS(stxsd, st64_i64) > VSX_LOAD_SCALAR_DS(stxssp, st32fs) > > > 2) VSX_VECTOR_LOAD_STORE is confusing and should be split into > > separate VSX_VECTOR_LOAD and VSX_VECTOR_STORE macros > > Good idea. I also removed (what I assume) are redundant set_cpu_vsr* > and get_cpu_vsr* calls. > > > Does that sound reasonable? I'm also thinking that we should consider > > adding a CC to stable for patches 4, 5 and 9 in this series since > > these are genuine regressions. > > Fine with me. If David agrees, I'm not sure if he can rebase them or > if I can send them manually if they have been already committed.
Usually going to stable is just a matter of pinging Mike Roth and
getting him to include it. I can queue if somewhere if you like, but
the stable cadance is so slow it tends to get forgotten a bit.
--
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_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
