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/ [11]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 [9]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 gem5-users@gem5.org
gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [10]
>>>>
_______________________________________________ gem5-users mailing list
gem5-users@gem5.org [12]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [13]
>>>
_______________________________________________ gem5-users mailing list
gem5-users@gem5.org [14]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [15]
>>
_______________________________________________ gem5-users mailing list
gem5-users@gem5.org [16]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [17]
>
>
_______________________________________________
> gem5-users mailing
list
> gem5-users@gem5.org
>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Links:
------
[1] mailto:gem5-users@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
mailto:gem5-users@gem5.org
[4]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[5]
mailto:gem5-users@gem5.org
[6]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[7]
mailto:gem5-users@gem5.org
[8]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[9]
mailto:nprem...@irisa.fr
[10]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[11]
http://reviews.gem5.org/r/1376/
[12] mailto:gem5-users@gem5.org
[13]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[14]
mailto:gem5-users@gem5.org
[15]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[16]
mailto:gem5-users@gem5.org
[17]
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
