On Tue, 2023-12-12 at 19:59 +0800, Jiahao Xu wrote: > > I guess here the problem is floating-point compare instruction is much > > more costly than other instructions but the fact is not correctly > > modeled yet. Could you try > > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640012.html > > where I've raised fp_add cost (which is used for estimating floating- > > point compare cost) to 5 instructions and see if it solves your problem > > without LOGICAL_OP_NON_SHORT_CIRCUIT? > I think this is not the same issue as the cost of floating-point > comparison instructions. The definition of LOGICAL_OP_NON_SHORT_CIRCUIT > affects how the short-circuit branch, such as (A AND-IF B), is executed, > and it is not directly related to the cost of floating-point comparison > instructions. I will try to test it using SPECCPU 2017.
The point is if the cost of floating-point comparison is very high, the middle end *should* short cut floating-point comparisons even if LOGICAL_OP_NON_SHORT_CIRCUIT = 1. I've created https://gcc.gnu.org/PR112985. Another factor regressing the code is we don't have modeled movcf2gr instruction yet, so we are not really eliding the branches as LOGICAL_OP_NON_SHORT_CIRCUIT = 1 supposes to do. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
