This is the mail archive of the
mailing list for the GCC project.
Re: [rfc] subreg lowering pass / Overcoming double-set difficulties for CC re-use
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- Cc: Björn Haase <bjoern dot m dot haase at web dot de>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 17 Oct 2006 10:33:34 -0400 (EDT)
- Subject: Re: [rfc] subreg lowering pass / Overcoming double-set difficulties for CC re-use
- References: <Pine.LNX.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <Pine.BSF.firstname.lastname@example.org> <20061016145055.GF24007@sygehus.dk> <Pine.BSF.email@example.com> <20061017084214.GI24007@sygehus.dk>
On Tue, 17 Oct 2006, Rask Ingemann Lambertsen wrote:
> It's the "code size and performance regressions" part. I chose CC_REG
> over (cc0) for the i8086 partly because I expected shorter and faster code
> from CC_REG.
The ix86 (i8086 in your case) is different because you have
moves and adds that don't change condition codes; I'd say it's
not a *typical* cc0 target, like m68k and CRIS. You don't have
to split cbranch into compare and branch after reload.
My work on CRIS CC_REG is all "on the back-burner" and I'll have
to re-do it anyway because lots have changed and I expect lots
of changes (good ones, I presume) from the data-flow branch
AFAIR, besides combine having trouble combining some of the
parallels as good as with CC0, it was all little bits here and
there that got confused mostly because a register is being
clobbered and then set and used in the same basic block. All
bugs, so in the end you'd theoretically get equivalent code.
Don't expect measurably shorter and faster code for CC_REG than
for cc0 (with figures not in the noise); that's not what I saw