Richard Henderson <r...@twiddle.net> 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 <r...@twiddle.net> 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 <nik...@linux.vnet.ibm.com> >>>>> --- >>>>> 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? Regards Nikunj
