Hi Ali,
I just found a little thing that need to be added to the last
modification you have proposed. This code:
if (!(condCode == COND_AL || condCode == COND_UC))
(*uop)->setFlag(StaticInst::IsCondControl);
Should be:
if (!(condCode == COND_AL || condCode == COND_UC))
(*uop)->setFlag(StaticInst::IsCondControl);
else
(*uop)->setFlag(StaticInst::IsUncondControl);
Thanks,
Nathanaël
Le 06/09/2012 19:05, Ali Saidi a écrit :
OK. I'll get these patches committed.
Thanks,
Ali
On 05.09.2012 10:27, Nathanaël Prémillieu wrote:
Hi Ali,
Thanks for the last modification, everything works well now.
If my numbers are correct, for some benchmarks, the majority of the
mispredictions were not flagged as control instructions (50%~60% on
average, up to 98%) and for some other it was negligible (1% or even less).
Nathanaël
Le 04/09/2012 03:10, Ali Saidi a écrit :
Hi Nathanaël, How big was the stat before this out of curiosity? Have
you run into any problems with the patch? Something like this might
solve your problem with the remaining ones: diff -r 42807286d6cb
src/arch/arm/insts/macromem.cc --- a/src/arch/arm/insts/macromem.cc
Tue Aug 28 17:57:51 2012 -0500 +++ b/src/arch/arm/insts/macromem.cc
Mon Sep 03 20:10:02 2012 -0500 @@ -104,6 +104,12 @@ // into the final
one later *++uop = new MicroLdrUop(machInst, INTREG_UREG1,
INTREG_UREG0, up, addr); + if (reg == INTREG_PC) { +
(*uop)->setFlag(StaticInst::IsControl); + if (!(condCode == COND_AL
|| condCode == COND_UC)) +
(*uop)->setFlag(StaticInst::IsCondControl); +
(*uop)->setFlag(StaticInst::IsIndirectControl); + } } else { //
Otherwise just do it normally if (reg == INTREG_PC && exception_ret)
{ @@ -113,6 +119,12 @@ } else { *++uop = new MicroLdrUop(machInst,
regIdx, INTREG_UREG0, up, addr); + if (reg == INTREG_PC) { +
(*uop)->setFlag(StaticInst::IsControl); + if (!(condCode == COND_AL
|| condCode == COND_UC)) +
(*uop)->setFlag(StaticInst::IsCondControl); +
(*uop)->setFlag(StaticInst::IsIndirectControl); + } } } } else {
Please let me know if that works out. Ali On Sep 3, 2012, at 4:06 AM,
Nathanaël Prémillieu wrote:
Hi Ali, The patch seems to resolve most of my problems, thanks a
lot. I have added a statistic to see how many instructions are
detected as mispredicted (by the inst->mispredicted() function) but
have not their IsControl flag set. In most of the benchmarks, it's
now 0. However, I still have one benchmark that have one instruction
that has a problem (more event are detected, but only one is
committed). It is a MicroLdrUop ("ldr_uop") instruction. Nathanaël
Le 29/08/2012 20:39, Ali Saidi a écrit :
Hi Nathanaël, I just posted some code that should address both the
issues you found. I haven't tested it yet, but let me know what you
find. http://reviews.gem5.org/r/1376/Thanks, Ali On 28.08.2012
12:01, Ali Saidi wrote:
Hi Nathanaël, Sent from my ARM powered mobile device On Aug 28,
2012, at 11:34 AM, Nathanaël Prémillieu <nprem...@irisa.fr
<mailto:nprem...@irisa.fr>nprem...@irisa.fr>> wrote:
Hi Ali, Thank for your response. I was thinking that data
instructions as branch was a specificity of ARMv7. In The ARM
Architecture Reference Manual, p. 170, it is stated that: "In
ARMv7, a processor in ARM state can also enter Thumb state (and
change to executing Thumb instructions) by executing an ADC, ADD,
AND, ASR, BIC, EOR, LSL, LSR, MOV, MVN, ORR, ROR, RRX, RSB, RSC,
SBC, or SUB instruction that has the PC as destination register
and does not set the condition flags." I don't currently know if
it happens a lot and if it is responsible for a significative
part of the detected mispredictions. I will send some update when
I will have numbers.
Thanks for looking into it and please let us know. Looking at the
reference manual it appears as though I wasnt quite correct. See
table D4 in version 406B of the manual or I5 in version 406C. It
seems like we're missing a few that aren't deprecated.
I have started to modify the src/arch/arm/isa/insts/data.isa file
and it seems to work. For the load instructions,
LOAD_REG_AN_PN_SN_UN_WN_SZ4, LOAD_IMM_AN_PN_SN_UN_WN_SZ4,
LOAD_REG_AY_PN_SN_UN_WN_SZ4 and LOAD_IMM_AY_PN_SN_UN_WN_SZ4 are
not split in two and the control flag is not set when it is
necessary.
Hrm. This is probably a bug. Thanks, Ali
Thanks, Nathanaël Le 28/08/2012 15:32, Ali Saidi a écrit :
Hi Nathanaël, The use of data instructions as branches is
deprecated so we chose not to mark them as branches and I'd hope
you're not seeing too much use of them. If you care the isBranch
kwarg can be passed to the various data instructions in
src/arch/arm/isa/insts/data.isa like it is for the mov
instruction to mark these as branches. As for the loads, I
believe these are correct, although it's always possible we
missed some. In gem5 the load operations are turned into to uops
one that does the memory load and a second that is the control
instruction. Is this not what you're observing? Thasks, Ali On
Aug 28, 2012, at 4:35 AM, Nathanaël Prémillieu wrote:
Hi All, Any thoughts on that matter ? Because not having these
instructions identified as control instructions causes the
branch predictor to not predict them, increasing the number of
branch mispredictions. It seems that some load instructions
have also this problem. Thanks, Nathanaël Le 23/08/2012 01:19,
Nathanaël Prémillieu a écrit :
Hi All, I happen to see that for data instructions in the ARM
ISA (for example an ADD) that have the PC as their destination
register are not set as control instructions (i.e. the flag
IsControl is not set). I was wondering whether it is a bug or
it has some logic. Thanks, Nathanaël
_______________________________________________ gem5-users
mailing list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users
mailing list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users
mailing list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users
mailing list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing
list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing
list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing
list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing
list gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
