> Maybe we need to introduce new option like 'vr2gpr-cost' here? Or just > consider they would be the same. > If we need a new option that indicate the cost from vr2gpr, this may not be > good fix up to a point.
Is the issue in the PR that the default VR2GR (== 2) is too expensive and when we use GR2VR (== 0) it just works? There will surely be uarchs where the latency is asymmetric but my first hunch was that we can get away with not modelling this for now. However, having --param=gr2vr imply vr2gr is not ideal either and rather misleading, even if it's just for testing. Therefore I'm leaning towards biting the bullet and introducing the new param. -- Regards Robin
