Re: [patch] allow target config to state r18 is fixed on aarch64

2018-11-09 Thread Andrew Pinski
On Fri, Nov 9, 2018 at 10:09 AM Olivier Hainque wrote: > > Hello Wilco, > > Would you have further thoughts on the patches proposed in > > https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01453.html > > ? > > There was: > > 1) * config/aarch64/aarch64.c (PROBE_STACK_FIRST_REG) : Redefine as > R

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-11-09 Thread Olivier Hainque
Hello Wilco, Would you have further thoughts on the patches proposed in https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01453.html ? There was: 1) * config/aarch64/aarch64.c (PROBE_STACK_FIRST_REG) : Redefine as R9_REGNUM instead of 9. (PROBE_STACK_SECOND_REG): Redefine as R10_REGNUM

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-23 Thread Olivier Hainque
Hi Wilco, > On 18 Oct 2018, at 19:08, Wilco Dijkstra wrote: >> I wondered if we could set it to R11 unconditionally and picked >> the way ensuring no change for !vxworks ports, especially since I >> don't have means to test more than what I described above. > > Yes it should always be the same

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-18 Thread Wilco Dijkstra
Hi Olivier, > STATIC_CHAIN_REGNUM still needs to be adjusted directly I think. > > I wondered if we could set it to R11 unconditionally and picked > the way ensuring no change for !vxworks ports, especially since I > don't have means to test more than what I described above. Yes it should always

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-18 Thread Olivier Hainque
Hi Kyrill, > On 16 Oct 2018, at 18:33, Kyrill Tkachov wrote: > >> I'm happy to move that part to aarch64_conditional_register_usage >> if that's considered more canonical of course. > > I don't think it's more canonical, and it is a run-time thing, whereas your > patch changes things > at conf

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-18 Thread Olivier Hainque
> On 18 Oct 2018, at 15:10, Olivier Hainque wrote: > > The only difference there would be wrt to this part > is the use of the macro within called_used_regs[] as well, > part of what we discussed with Kyrill. Ah, no, call_used[r18] is 1 currently. Will give this some thought ...

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-18 Thread Olivier Hainque
> On 18 Oct 2018, at 14:14, Sam Tebbs wrote: > > > > On 10/12/2018 07:43 PM, Olivier Hainque wrote: >>> On 12 Oct 2018, at 05:50, Kyrill Tkachov >>> wrote: >>> >>> CC'ing the aarch64 maintainers as they'll have to approve it. >>> I'm guessing you've tested this in the usual way (bootstrap

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-18 Thread Sam Tebbs
On 10/12/2018 07:43 PM, Olivier Hainque wrote: On 12 Oct 2018, at 05:50, Kyrill Tkachov wrote: CC'ing the aarch64 maintainers as they'll have to approve it. I'm guessing you've tested this in the usual way (bootstrap and test)? Sorry, I failed to mention the testing indeed. We don't have a

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-16 Thread Kyrill Tkachov
Hi Olivier, On 12/10/18 19:43, Olivier Hainque wrote: Hi Kyrill, Thanks for your feedback! On 12 Oct 2018, at 05:50, Kyrill Tkachov wrote: CC'ing the aarch64 maintainers as they'll have to approve it. I'm guessing you've tested this in the usual way (bootstrap and test)? Sorry, I failed to

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-12 Thread Olivier Hainque
Hi Kyrill, Thanks for your feedback! > On 12 Oct 2018, at 05:50, Kyrill Tkachov wrote: > > CC'ing the aarch64 maintainers as they'll have to approve it. > I'm guessing you've tested this in the usual way (bootstrap and test)? Sorry, I failed to mention the testing indeed. We don't have a nativ

Re: [patch] allow target config to state r18 is fixed on aarch64

2018-10-12 Thread Kyrill Tkachov
Hi Olivier, On 10/10/18 22:40, Olivier Hainque wrote: Hello, The aarch64 "platform register" r18 is currently unconditionally used as a scratch register by gcc. Working on a VxWorks port for this arch (that we plan to contribute soon), we discovered that VxWorks has an internal use of this reg