This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: pa64 mul,div,mod via millicode
- To: amodra at one dot net dot au
- Subject: Re: pa64 mul,div,mod via millicode
- From: law at redhat dot com
- Date: Tue, 12 Jun 2001 19:02:53 -0700
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <20010531083314.K12034@squeak.one.net.au>you write:
>
> pa64 millicode calls use r2 as the return pointer reg, but pa.md lies
> and says r31, the return pointer for pa32, is clobbered. This results
> in r2 being used across millicode calls, with less than satisfactory
> results. Found when compiling linux kernel mm/slab.c
>
> * config/pa/pa.c (emit_hpdiv_const): Return reg is r2 for 64-bit
> millicode.
> (insn_refs_are_delayed): Correct comment.
> * config/pa/pa.h (INSN_REFERENCES_ARE_DELAYED): Likewise.
> * config/pa/pa.md (mulsi3): If TARGET_64BIT, clobber r2
> instead of r31. Make associated insn !TARGET_64BIT, and
> provide an additional 64-bit insn that clobbers r2.
> (divsi3): Likewise.
> (udivsi3): Likewise.
> (modsi3): Likewise.
> (umodsi3): Likewise.
>
> OK for mainline and branch?
Hmmmm, something is odd here.
I believe the mul/div millicode routines already handle this. THey
emit a clobber of reg 2 (see the define_expands and search for TARGET_64BIT).
They still emit a clobber of reg31 which is redundant, but not harmful.
Now I do believe we might be dying a horrible death for the special cases
handled by emit_hpdiv_const. Presumably you're getting down that path
because you're not allowing xmpyu in the kernel, which in turn affects
how we handle divide by constants. Right?
jeff