Why are stores in the SQ assumed to have valid addresses?
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
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 muke101@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
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 muke101@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-leave@gem5.org
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 muke101@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-leave@gem5.org
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-leave@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