------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-10 00:04 ------- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f obje
> The problem that i have is it the argument pointer does not have a fixed > value. it is assigned to a hard register sometimes during reload. Function.c generates an insn to copy it to a pseudo during rtl expansion. This is the so called internal argument pointer. It is assigned a hard register during reload. A copy is needed because the incoming argument pointer is a call clobbered register. The register used for the incoming argument pointer never changes. After the copy is made, the compiler is free to make whatever use it wants of the argument pointer register. If the internal argument pointer was removed, we would have to copy the incoming argument pointer to a fixed register in the prologue, or save and restore the argument pointer register across calls. I'm not sure either of these approaches is an improvement over what we have now. When a call is made, the pa call expander emits insns to load the argument pointer suitably for the call using virtual_outgoing_args_rtx. We don't restore the argument pointer after a call. However, we do this for the PIC register. The thinking behind the current approach is that accesses to the argument block are much less frequent than accesses using the PIC register. Typically, the argument pointer is only needed for calls which have more than eight arguments or for va_args. The generic copy method has always worked reasonably well although there are some tail call optimizations that don't occur when it is used. It probably would be possible to handle the argument pointer in a manner similar to the way we handle the PIC register. This is a bit tricky. The details of regarding the handling of the argument pointer would have to be hidden until after reload. We have some ugly post-reload splitters to handle this for the PIC register. The downside is we lose the use of a register when we don't need an argument pointer. I have the impression that you are confused about the reason the argument pointer isn't fixed. Reload doesn't modify its incoming value. Reload also can't eliminate it because it there isn't a fixed relationship to the stack pointer (or the frame pointer). So, reload doesn't affect its liveness. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398