Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Thu, Nov 24, 2022 at 8:25 AM HAO CHEN GUI <guih...@linux.ibm.com> wrote: >> >> Hi Richard, >> >> >> 在 2022/11/24 4:06, Richard Biener 写道: >> > Wouldn't we usually either add an optab or try to recog a canonical >> > RTL form instead of adding a new target hook for things like this? >> >> Thanks so much for your comments. Please let me make it clear. >> >> Do you mean we should create an optab for "setb" pattern (the nested >> if-then-else insn) and detect candidate insns in ifcvt pass? Then >> generate the insn with the new optab? > > Yes, that would be one way to do it. Another way would be to > generate a (to be defined) canonical form of such instruction and > see whether it can be recognized (whether there's a define_insn > for it). > > Note that were just things that came into my mind here, I'm not too > familiar with how we handle such situations but at least I'm not > aware of dozens of target hooks to handle instruction availability.
Yeah, this was my reaction too. The patch does use recog for the conditional set itself, which is good, but I'm not sure from the patch what the target hook is supposed to do in preparation for the recog. I think it'd be better to avoid having too many hooks that take noce_if_info parameters. It's really just a bunch of internal pass state, rather than something that was designed to be a public interface. Currently we have one hook that takes noce_if_info parameters, for costing. That's still one more than I'd like, but at least there are no correctness concerns and, if someone changes noce_if_info in future, just rebuilding cc1 for the affected targets should be good enough as far as testing goes. If we start using hooks for code generation too, we're effectively distributing the ifcvt pass across targets, which makes the pass harder to maintain. Thanks, Richard
