Senthil Kumar Selvaraj writes:
> Georg-Johann Lay writes: > >> >> Finally, some general remarks: > > The work on my github branch was not complete - I'd blindly followed > whatever the CC0 Transition wiki mentioned (the first three steps of > case #2), and fixed any regression fallout (for ATmega128). > > I intend to try out a define_subst/early clobber of reg_cc based > approach (inspired by the cris port) and see if that can help avoid the > proliferation of define_insn_and_splits. Will update how that works out. I had some time this past week to try implementing some of the changes you suggested. > >> >> 2) We just saw 100reds of insns being dublicated, basically the whole >> machine description except for the few insns that leave cc alone. >> Isn't is possible to use define subst for the bulk of the insns and >> get a neat code that's better to grasp and to maintain? >> After all it's just appending a clobber of reg_cc, and in the current >> proposal almost 50% of the backend is just redundent repetitions of >> previous insns. I could not find a way to get define_subst to do define_insn_and_split - other targets using the same approach (pdp11, h8300) have the duplication as well. >> >> 4) Many insns don't have reloads and don't need to be turned into a >> splitter + yet another insns, it should be all right to clobber >> reg_cc from the very start. Or am I missing something? I think >> I marked all places, but it should be easy enough to spot them. If I remove the define_insn_and_split and add a (clobber (reg:CC REG_CC)) to the define_insn itself for xcall patterns, then the producer of the pattern (define_expand, output template of define-insn-and-split/define-split etc.. or C code) needs to modified to include the clobber of REG_CC in a PARALLEL, so that's a whole bunch of changes. If that is done at define_expand, for example, then similar patterns that do not use the hard regs (non-call variants) will also need to be modified to add the clobber, and therefore there's no point in define_insn without clobber and split after reload with clobber for those patterns. Did I get that right? FWIW, I'm also working on a parallel implementation that clobbers REG_CC in all patterns from the start (with matching clobbers in define_expand etc..) - still not in good enough shape though. It will avoid duplication, but at the expense of modification of nearly every pattern to emit or accept a clobber of REG_CC. Regards Senthil
