According to the Alpha reference manual, there's no need to serialize on store conditionals; if the programmer cares about ordering of memory accesses around the store conditional, then an MB or WMB instruction must be added. So making store conditionals serialize is unnecessary from an architectural perspective.
I see that the comment says "This is mainly due to lack of support for out-of-order operations of either of those classes of instructions", so it may be that there's something in the O3 pipeline model that doesn't support register renaming on store conditionals (though I don't know why they wouldn't work). I think Kevin would need to comment on this since he's the one that wrote that code and that comment (even though it was 3.5 years ago so he may not remember). I'd say just remove that check and see what happens... please let us know if you try it whether it causes any problems or not. Thanks, Steve On Mon, Dec 7, 2009 at 3:03 PM, ef <[email protected]> wrote: > Hello, > > I have been doing some research on PARSEC and M5. There seems to be a lot of > serialization causing bad IPC in Parsec Benchmarks. Serialization of Store > Conditionals is ne issue, at this point I am unable to determine whether the > issue is M5 Alpha implementation or just that the Alpha ISA is to old. I > tried seeing what other architecture do, but there are LL/SC in Intel > implemtations (they use a lock prefit tag on each instruction). > > If it turns out that we dont need to make LL/SC unserial, any possible ideas > on solutions? Although I am not sure thats the case, I just had difficulty > finding literature in terms of alpha with LL/SC. > > Here is what I am talking about: > cpu/o3/rename_impl.hh > Line 649: > > // Handle serializeAfter/serializeBefore instructions. > // serializeAfter marks the next instruction as serializeBefore. > // serializeBefore makes the instruction wait in rename until the > ROB > // is empty. > > // In this model, IPR accesses are serialize before > // instructions, and store conditionals are serialize after > // instructions. This is mainly due to lack of support for > // out-of-order operations of either of those classes of > // instructions. > if ((inst->isIprAccess() || inst->isSerializeBefore()) && > !inst->isSerializeHandled()) { > DPRINTF(Rename, "Serialize before instruction encountered.\n"); > > if (!inst->isTempSerializeBefore()) { > renamedSerializing++; > inst->setSerializeHandled(); > } else { > renamedTempSerializing++; > } > > // Change status over to SerializeStall so that other stages > know > // what this is blocked on. > renameStatus[tid] = SerializeStall; > > serializeInst[tid] = inst; > > blockThisCycle = true; > > break; > } else if ((inst->isStoreConditional() || inst->isSerializeAfter()) > && > !inst->isSerializeHandled()) { > DPRINTF(Rename, "Serialize after instruction encountered.\n"); > > renamedSerializing++; > > inst->setSerializeHandled(); > > serializeAfter(insts_to_rename, tid); > } > > > Thanks, > EF > > > > > On Wed, Dec 2, 2009 at 11:40 AM, Steve Reinhardt <[email protected]> wrote: >> >> Good question... it's not clear they need to be. I think the overall >> motivation is to make sure that lock acquire/release operations are >> properly ordered, but for Alpha that should be enforced via separate >> barrier instructions anyway. I assume this is happening as a side >> effect of the instructions being marked as "locked"? Can you point to >> the code you're referring to? >> >> Steve >> >> On Wed, Nov 18, 2009 at 7:03 PM, ef <[email protected]> wrote: >> > Hello, >> > Why are stl_c and stq_c serializing instructions in the O3 model >> > during the renaming stage? >> > >> > Thanks >> > EF >> > _______________________________________________ >> > m5-users mailing list >> > [email protected] >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
