Hans-Peter Nilsson writes:
> On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote: >> As you can deduce from the (set_attr "cc" ..), only constraint >> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged. > > Yes, I recognize that. > >> My first version of the port adds a post-reload splitter that adds a >> (clobber (reg:CC REG_CC)) unconditionally, and it appears to work. > > Ouch, temporarily lying to gcc here. > >> If I >> do want to add the clobber conditionally, would something like the below >> be a good way to do it (get_cc_reg_clobber_rtx returns either const0_rtx >> or cc_reg_rtx based on get_attr_cc (insn))? Or is there a better/cleaner way? > > I suggest having a look at what I did for the CRIS port. > Check the git history. > > In short: > - Add the clobber initially, to *all* patterns. > - Add postreload splitters for the special combinations that > don't clobber CC (ones without clobbering CC). > - Use the old "cc" attribute to control and generate > clobber/useful CC-setting alternatives (for various new CC_ > modes) with use of define_subst. This sounds like a great plan - the idea of always generating insn variants for however many CCmodes are available, and then using cc_enabled to disable them selectively (based on the attribute value corresponding to the alternative chosen) looks really neat. I did not understand the purpose of subst_attr for "ccnz" "ccnzvc" and "cccc" though - wouldn't a (set_attr "cc_enabled", "...") do the same thing? Also, I already have a version that hides REG_CC until reload (based on the suggestion in the wiki page), but I guess this approach will work equally well with that too? Regards Senthil