This is the mail archive of the gcc@gcc.gnu.org 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: a strange infelicity of register allocation


> 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?


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