Thanks a lot! I was troubled by this too!
And to add a little info, here is where the _size is set. When a store
reaches this stage, its translation has been finished.
Thanks a lot!
#0 gem5::o3::LSQUnit::LSQEntry::size at lsq_unit.hh:143
#1 in gem5::o3::LSQUnit::write at src/cpu/o3/lsq_unit.cc:1615
#2 in gem5::o3::LSQ::write at src/cpu/o3/lsq.cc:1539
#3 in gem5::o3::LSQ::pushRequest at src/cpu/o3/lsq.cc:849
#4 in gem5::o3::CPU::pushRequest at src/cpu/o3/cpu.hh:556
#5 in gem5::o3::DynInst::writeMem at src/cpu/o3/dyn_inst.cc:440
#6 in gem5::X86ISA::writeMemTiming at src/arch/x86/memhelpers.hh:195
#7 in gem5::X86ISAInst::St::initiateAcc at
build/X86_MESI_Two_Level/arch/x86/generated/exec-ns.cc.inc:19125
#8 in gem5::o3::DynInst::initiateAcc at src/cpu/o3/dyn_inst.cc:374
#9 in gem5::o3::LSQUnit::executeStore at src/cpu/o3/lsq_unit.cc:673
#10 in gem5::o3::LSQ::executeStore at src/cpu/o3/lsq.cc:249
#11 in gem5::o3::IEW::executeInsts at src/cpu/o3/iew.cc:1192
#12 in gem5::o3::IEW::tick at src/cpu/o3/iew.cc:1422
#13 in gem5::o3::CPU::tick at src/cpu/o3/cpu.cc:363
On 2024-09-19 16:15, muke101 via gem5-dev wrote:
Solved this question for anyone interested, posted the full answer in that
github issue but basically it turns out stores without a valid address also
have an access size of 0 until they're assigned an address at execution, and
there's a guard in the SQ search loop that checks against the size being 0.
Sent from Proton Mail Android
-------- Original Message --------
On 17/09/2024 13:46, muke101 via gem5-dev <gem5-dev@gem5.org> wrote:
Sorry, forgot to link the github issue I mentioned:
https://github.com/orgs/gem5/discussions/650
Sent from Proton Mail Android
-------- Original Message --------
On 17/09/2024 13:45, muke101 <muke...@protonmail.com> wrote:
> Hi, I'm doing some gem5 hacking for research and have been confused over
the timing of when loads search the store queue (SQ) and when stores have valid
addresses that can be compared against. Gem5 includes an assert in the read()
method in the LSQ unit that the addresses of all stores before the executing loads
are valid, but I don't understand how this can be guaranteed in OoO execution.
>
> I found a github issue which explains the issue in more detail with code
examples, but hasn't received any answers. I'm hoping someone here could take a
look and shed light on what's going on with this part of the code.
>
> In my case, I'd like to be able to force executing loads to be dependent
on the first older store which has an unknown address, in order to simulate an OoO
core without memory dependence prediction. I had imagined implementing this during
the store forwarding search in the same way a load is made dependent on a store
with a partial address overlap, but again for some reason it's assumed that by the
time a load is forwarding all the previous stores have known addresses.
>
> Any info would be appreciated, thanks.
>
> Sent from Proton Mail Android
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
När du har kontakt med oss på Uppsala universitet med e-post så innebär det att
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
E-mailing Uppsala University means that we will process your personal data. For
more information on how this is performed, please read here:
http://www.uu.se/en/about-uu/data-protection-policy
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
