Yeah, l thought they should be the same but it seems not that correct after re-consideration. Let me have another shoot for this issue.
Pan -----Original Message----- From: Robin Dapp <[email protected]> Sent: Monday, February 2, 2026 5:15 PM To: Li, Pan2 <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; Chen, Ken <[email protected]>; Liu, Hongtao <[email protected]> Subject: Re: [PATCH v1 1/2] RISC-V: Bugfix adjust_stmt_cost doesn't honor param=gpr2vr-cost [PR123916] > 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
