On Thu, Aug 3, 2023 at 10:31 PM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > On 8/3/23 17:38, Vineet Gupta wrote: > > >> ;-) Actually if you wanted to poke at zicond, the most interesting > >> unexplored area I've come across is the COND_EXPR handling in gimple. > >> When we expand a COND_EXPR into RTL the first approach we take is to > >> try mov<mode>cc in RTL. > >> > >> Unfortunately we don't create COND_EXPRs all that often in gimple. > >> Some simple match.pd patterns would likely really help here. > >> > >> The problem is RTL expansion when mov<mode>cc FAILs is usually poor at > >> best. So if we're going to add those match.pd patterns, we probably > >> need to beef up the RTL expansion code to do a better job when the > >> target doesn't have a mov<mode>cc RTL pattern. > > > > Ok, I'll add that to my todo list. > You might want to reach out to Andrew Pinski if you do poke at this. I > made a reference to this issue in a BZ he recently commented on. It was > an x86 issue with cmov generation, but the same core issue applies -- > we're not generating COND_EXPRs very aggressively in gimple.
Yes I have some ideas of producing more aggressively COND_EXPR in either isel or in the last phiopt. There is also a canonicalization form issue dealing with `bool * b` representing `bool ? b : 0` where isel could select between the COND_EXPR and multiply too. This is the issue Jeff is talking about too. Thanks, Andrew > > jeff
