This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: minor code-quality regression vs. 2.95
- To: law at cygnus dot com
- Subject: Re: minor code-quality regression vs. 2.95
- From: "Philippe De Muyter" <phdm at macqel dot be>
- Date: Mon, 24 Apr 2000 06:33:22 +0200 (CEST)
- Cc: zack at wolery dot cumb dot org, cpopetz at cygnus dot com, gcc at gcc dot gnu dot org
Zack Weinberg wrote :
> Hmm... expand_divmod calls do_cmp_and_jump, which looks like it would
> be the appropriate place to teach GCC that DImode < 0 or >= 0 can be
> done by looking only at the high word. But when I do that (see patch
> below), it doesn't help, because i386 has a cmpdi pattern. This
> seems silly to me... why not let the generic code synthesize it?
I had similar problems with DImode for m68k. If one wants to provide
`adddi3' and `subdi3' because the cpu can do it fast, one ends to provide
also `cmpdi', `anddi', `xordi', `iordi' and maybe others, because
`combine' would not combine anything of the CPU-DImode world with something
of the expmed-DImode world.
`expmed' is actually called too early. It should probably not split cmpdi,
anddi, xordi and iordi if the md-file provides other real DImode patterns,
and let a stage after combine split them using cmpsi, andsi, xorsi and iorsi.
Another way would be to let gcc know that there are `add-with-carry' and
`substract-with-borrow' insns, and keep track of the carry/borrow flag,
but that's probably not a simple task, and that would only solve the problems
with the adddi3 and subdi3 patterns, not with muldi or divdi.
Philippe