I ran some more tests and it doesn't always break at the same instruction (
MOV_R_M). However, what seems to be common is that the instruction causing
the problem (let's call it instruction A) conflicts with another
instruction in the 'checkSnoop' function in 'src/cpu/o3/lsq_unit_impl.hh'.
Therefore, 'A' ends up being faulty with ReExec and consequently marked as
executed and sent to commit but never actually gets to commit before being
executed again.
What I understood from the comments in this function is that offending
instructions should be squashed (since I amusing X86 which sets needsTSO to
True and consequently force_squash to True as well). But looks like the
Instructions are not squashed as far as I can tell.
I am not sure if this helps narrow down the problem or not but I hope it
helps!
On Thu, Sep 12, 2019 at 2:52 PM Shehab Elsayed wrote:
> Looks like this is the instruction causing the assertion failure
>
> MOV_R_M : ld r9, DS:[rdx + 0x10]
>
>
>
> On Wed, Sep 11, 2019 at 5:20 PM Pouya Fotouhi
> wrote:
>
>> If you use --debug-flags=ExecAll,Decode and narrow down your trace to the
>> Ticks that you know the load is failing with --debug-start and --debug-end
>> you should be able to get that.
>>
>> Best,
>>
>> On Wed, Sep 11, 2019 at 2:15 PM Shehab Elsayed
>> wrote:
>>
>>> Is there a way to get the macroop from the corresponding instruction
>>> pointer?
>>>
>>>
>>> On Wed, Sep 11, 2019 at 5:07 PM Pouya Fotouhi
>>> wrote:
>>>
Hi Shehab,
Can you please confirm what is the macroop that is issuing that load? I
suspect it's one of the 128-bit instructions (maybe recently non-temporal
ones that I added) that are executed as two 64-bit loads, and possibly the
second one is failing due to the cda check that we do, and that stops the
load from being committed.
Best,
On Wed, Sep 11, 2019 at 1:16 PM Shehab Elsayed
wrote:
> So actually load instruction gets executed twice causing the assertion
> to fail on the second time.
>
> 769413949: system.switch_cpus.iew.lsq.thread0: Doing memory access
> for inst [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2)
> 769413949: system.switch_cpus.iew.lsq.thread0: Load [sn:15059405]
> not executed from fault
> 769413949: system.switch_cpus.iew.lsq.thread0: 1- Setting
> [sn:15059405] as executed (I added this message to track when LSQ
> instructions are set as executed)
>
> I believe this instruction should then be committed and removed from
> the LSQ before before executed again, however, this does not happen.
> Instead it gets executed again before being removed and then comes the
> assertion failure that it has already executed.
>
> I see that it gets sent to commit
>
> 769413949: system.switch_cpus.iew: Sending instructions to commit,
> [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2).
>
> but it never actually gets to commit and removed from LSQ.
>
>
> On Mon, Sep 9, 2019 at 3:01 PM Pouya Fotouhi
> wrote:
>
>> You can try dumping Exec trace for the last few million ticks and see
>> what is going on in your LSQ and why you have load instruction that is
>> not
>> executed.
>>
>> Best,
>>
>> On Mon, Sep 9, 2019 at 11:28 AM Shehab Elsayed
>> wrote:
>>
>>> I am not sure that prefetch_nta is the problem. For different runs
>>> the simulation would fail after different periods after printing the
>>> prefetch_nta warning message. Also, from what I have seen in
>>> different posts it seems that this warning has been around for a while.
>>>
>>> I tried compiling my hello world program with -march=athlon64 alone
>>> and together with -O0 and the the same problem happens.
>>>
>>> Also, the I am building my benchmark on the disk image directly
>>> using qemu and the gcc on the image is versio 5.4.0
>>>
>>>
>>>
>>> On Sun, Sep 8, 2019 at 4:14 PM Pouya Fotouhi
>>> wrote:
>>>
Hi Shehab,
Good, that's "progress"!
My guess off the top of my head is that you used a "more recent"
compiler (compared to what other gem5 users tend to use), and thus some
instructions are being generated that were not critical to the
execution of
applications other users had so far (and that's mostly why those
instructions are not yet implemented). I think you have two options:
1. You can try implementing prefetch_nta, and possibly ignore
the non-temporal hint (i.e. implement it as a cacheable prefetch).
You can
start by looking at the implementation of other prefetch
instruction we
have in gem5 (basically you can do the same :) ).
2. Try compiling your application (I think we are still talking
