This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: a strange infelicity of register allocation
- To: zack at rabi dot columbia dot edu (Zack Weinberg)
- Subject: Re: a strange infelicity of register allocation
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Tue, 26 Jan 1999 15:44:06 +0000 (GMT)
- Cc: law at cygnus dot com, amylaar at cygnus dot co dot uk, egcs at egcs dot cygnus dot com
> There is questionable code elsewhere, such as:
>
> decl -4112(%ebp)
> movl -4112(%ebp),%ecx
This is a CISC specific problem - load-store architectures don't see it since
they have to do a load first for the decrement, and then can inherit from the
store.
I think it could be tackled by something I'd call 'reverse inheritance' - you
remember when could have used the value in a register, and when you later
find a load of the same value, and the register is free from the desired use
to the load, the load can be moved upwards.
However, in some cases - like this one - this strategy increases code size
and issue bandwidth, so its use has to be conditionalized on ! optimize_size
and on compiling for a processor where simplicity of operations is more
important than the mere instruction count.
> C:
> buf = xrealloc (buf, op - buf);
> fp->buf = buf;
> return op - buf;
>
> becomes
>
> movl %ebx,%eax
> subl -4104(%ebp),%eax
> pushl %eax
> movl -4104(%ebp),%edx
> pushl %edx
> call xrealloc
> movl %eax,-4104(%ebp)
> movl 12(%ebp),%eax
> movl -4104(%ebp),%ecx
> movl %ecx,(%eax)
> subl %ecx,%ebx
> movl %ebx,%eax
> jmp epilogue
The first problem here is that (op - buf) hasn't been subjected to cse.
Is the address of buf taken anywhere in this function?