On 09/19/16 23:51, Jeff Law wrote:
> On 09/17/2016 05:29 PM, Bernd Edlinger wrote:
>> On 09/17/16 22:29, Jan-Benedict Glaw wrote:
>>> On Fri, 2016-09-09 21:40:38 +0000, Bernd Edlinger
>>> <bernd.edlin...@hotmail.de> wrote:
>>>> I think it is time to remove support for
>>>> INITIAL_FRAME_POINTER_OFFSET, which is no longer
>>>> used by any target today. This removes a bunch of conditional code,
>>>> and fixes a few bits
>>>> in the documentation. I'd say that part of the documentation is
>>>> quite out of sync, but I just
>>>> have to stop somewhere.
>>>> Bootstrapped and reg-tested on x86_64-pc-linux.gnu
>>> The vax backend doesn't yet define ELIMINABLE_REGS.
>> Oh, yes. I see. What a hack.
>> Then we should define it.
>> But simply returning zero for the fp to sp offset is not ok,
>> and even if the offset is not used for register eliminations
>> it should still be correct for rtx_addr_can_trap_p
>> to know the safe stack frame offset ranges.
>> I would assume a small performance improvement, when
>> rtx_addr_can_trap_p has correct data available.
>> How about this patch, it should at least fix the bootstrap.
>> Is it OK for trunk?
Jeff, I am sorry.
But I think I got the sign of the elimination offset wrong,
because I peeked at a stack-grows-upward target (hppa).
And the doc/tm.texi is not a big help either.
With my limited testing this did not make any difference.
Actually I have not touched any vax since I was a student.
And that is already quite a while ago...
I hope you don't mind when I commit it this way:
+#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
+ ((OFFSET) = get_frame_size ())