This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: choose_reload_regs V2.0

On Tue, 5 Sep 2000 Bernd Schmidt wrote:

> >       if (equiv != 0 && regno_clobbered_p (regno, insn))
> > 
> > This checks for clobbering only the first hard register (high part of the
> > constant). In this case, it is $2 on MIPS and %o0 on SPARC. Low part of the
> > constant is in $3 on MIPS and %o1 on SPARC, and those registers are clobbered
> > by the respective asm statement. So there is a problem.
> That looks like it could indeed be a problem.  I'd prefer to fix it by
> adding a mode argument to regno_clobbered_p, as in the second patch below.

> >    * reload1.c (choose_reload_regs): Test for clobbering inherited reload
> >  registers.
> I don't think this test should be needed.  If it's a clobbered operand, we
> should have appropriate earlyclobber information.  If there's a hard
> register that's explicitly clobbered in the insn, we have other mechanisms
> to prevent using it for inheritance.  (Although, now that I think of it,
> that may have been broken in 2.95.2.  Can you reproduce your problems with
> current mainline CVS?  This could be why the second testcase is failing.)
> I think this problem is simply a case of a missing earlyclobber in
> Could someone who is familiar with that machine description look at the first
> of the two patches below?

On Wed, 06 Sep 2000, Jeffrey A Law wrote:

>  > Patch #1:
>  >   * (adddi3_internal_1): Make operand 3 an earlyclobber.
>Looks good to me.  I also suspect adddi3_internal_2, subdi3_internal,
>and subdi3_internal_2 need similar fixes.  There's also a number of
>define_splits which look suspicious.  negdi2_internal appears to be OK.
>  > Patch #2:
>  >   * reload.c (regno_clobbered_p): Accept new arg, MODE, and use it
>  >   to handle multiword modes correctly.  All callers and the declaration
>  >   changed.

I agree that the third argument to regno_clobbered_p is more elegant solution
to the "equiv" problem. But I still don't agree with the first part, concerning
clobbering inherited reloads. The "md" solution is OK for addi_internal insn
on MIPS. The similar problem for add insn doesn't exist on SPARC, because MIPS
must use additional reg for CARRY. But, I tested egcs-20000904 snapshot on
SPARC with asm-statements (The CVS checkout take too long).
Here, I wasn't force "equiv" part of the problem, because it is now corrected.
The problem is still in the "inheritance" part. Here, for asm statement, its
clobber register list doesn't appear in earlyclobber list (as there are no
earlyclobbers in the insn). In the case of MIPS and addi_internal insn, this
won't happen as there is a test for earlyclobbers. But what about
asm-statements? C-code is:

extern int	printf(const char *, ...);
extern int x[8], y[8];

int main(void){

	long long a, b, c, aa, bb, cc;
	int i, z[8];

	for(i = 0; i < 8; i += 2){
		a = x[i];
		b = y[i];
		aa = x[i + 1];
		bb = y[i + 1];
		c = a*bb - aa*b;
		cc = a*b + aa*bb;
		c += ((long long)1 << 25);
		asm("mov %H0, %%o1\n\tadd %L0, %%o1, %%o1\n": : "r"((long long)1 << 25): "%o1", "%i5");
		cc += ((long long)1 << 25);
		c >>= 26;
		cc >>= 26;
		z[i] = (int)c;
		z[i + 1] = (int)cc;
	for(i = 0; i < 8; i++){
		printf("z[%02d]=%08x\n", i, z[i]);
	return 0;


The problematic part of the assembler output (that comes from asm) is:
   mov %o0, %o1
   add %o1, %o1, %o1
This clobbers %o1 in first insn, before using it in second insn. Register
pair o0:o1 is used as inherited reload register despite the fact that
lower part is destroyed. So reload_inherited[r] becomes true, and
rld[r].reg_rtx have the value of "o0:o1" rtx.

On Thu, 7 Sep 2000 Bernd Schmidt wrote:

> How about the patch below?  Note that it's untested; I'm having some problems
> building mips targets with current CVS.

I will try it as soon as I can.

Alan Goluban

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]