Segher Boessenkool schrieb:
On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
On Dec 17, 2020, at 6:21 AM, Segher Boessenkool <seg...@kernel.crashing.org>
wrote:
On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via
Gcc-patches wrote:
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.
Yeah, case #2 does not necessarily give the best result, but it usually
is the least work to do, so certainly a good choice under time pressure.
I was under the impression from what I read in the blog a year or two ago (when I did the pdp11
ccmode work) that "case 2" is the better answer for machines in which pretty much every
operation touches the condition codes. In other words, I understood that case 1 would for such
machines not be the right answer -- it wasn't just that "case 2 is easier".
Did I misunderstand? Is there a reason for machines such as pdp11, in which
basically every operation that handles data, even a move instruction, touches
CC, to use approach 1?
No, you didn't misunderstand. I said "not necessarily" for a reason :-)
If there are move insns that do *not* clobber CC, it can be different,
but if even move instructions do, a case #2 conversion is a good choice.
(This is all my opinion, but I think it is not controversial.)
As far as I understand, targets that clobber condition code in mov<mode>
or add<pmode>3 must use approach #2. #1 is not a problem if the target
still uses IRA (like avr does), but LRA cannot handle clobbers of the
condition code (in terms or explicit clobbers).
Hence, targets that clobber cc in mov<mode> or add<pmode>3 must
use #2 because IRA/reload will also be kicked out before very soon.
Or am I missing something?
Johann
