On Thu, 9 Nov 2023, Jeff Law wrote: > > Can we have the insn costing reverted to correct calculation? > What needs to happen is that code needs to be extended, not reverted. Many > codes have to be synthesized based on the condition and the true/false arms. > That's not currently accounted for.
How is maintaining zillions of variants of insn counts by hand (IIUC what you mean) going to be more efficient (or even practical maintenance-wise) than what the middle end did automagically? What exactly was wrong with the previous approach, and then why didn't your change include a proof of correctness in the form of testsuite cases verifying branch vs conditional move costing stays the same (or gets corrected if applicable) across your change? I guess I'll post my patch series regardless on the presumption that correct insn counting will have been reinstated for GCC 14 one way or another (i.e. by reverting commit 44efc743acc0 locally in my tree and then getting clean test results across the patch series) and we can take it from there. Also to make sure we're on the same page. I do hope it will be considered worthwhile despite this issue making it not ready for testsuite verification, as not only it adds new features, but it fixes numerous existing problems, plain bugs, and deficiencies as well which we currently have in conditional move handling. But it relies on correct costing for verification, which I couldn't have expected that will get broken again (regardless of your clearly good intentions). And I'd rather we had these test cases or otherwise costing regressions are easily missed (as indicated here). Maciej
