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: >>>> Hi, >>>> >>>> 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? > OK. > jeff
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 ()) Thanks Bernd.