This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638


"Uros Bizjak" <ubizjak@gmail.com> writes:

> 2007-10-08  Uros Bizjak  <ubizjak@gmail.com>
> 
> 	PR rtl-optimization/33638
> 	* explow.c (memory_address): When -fforce-addr is in effect,
> 	do not force addresses using virtual_outgoing_args_rtx or
> 	stack_pointer_rtx to a temporary register.

It's hard for me to be entirely happy with this patch.

Some processors don't have register offset addressing, so all access
to the stack is done by copying and adding registers.  It seems to me
that such processors might have trouble with dse.c as currently
written.

On the other hand, -fforce-addr is meaningful for stack addresses,
especially on architectures with only small stack pointer offsets or
for which register direct instructions are smaller than register
offset addresses.

If I understand the problem correctly, the issue is that the address
of a function argument was loaded into a register.  A later store
using that register was not noticed as being for a function argument,
and was eliminated as dead although it was not.  All would be well if
you knew that the store was for a function argument.  And, of course,
the issue only arises for const functions, as for a non-const function
all stores are live.

There is special code in calls.c to mark the stack usage of const
functions: around line 2700, in expand_call.  It seems to me that if
store_one_arg comes up with a different address, because it calls
memory_address, you should put that address also in
CALL_INSN_FUNCTION_USAGE.  That ought to fix the immediate problem as
well.

I think there is still a lurking issue, which is that in principle
dse.c really needs to record which stores may be for function
arguments.  I don't see a really good way to do that, though of course
it could be done by setting and propagating a register flag.

Ian


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