On 11/27/20 12:22 PM, Maciej W. Rozycki wrote:
> On Fri, 27 Nov 2020, Ulrich Weigand wrote:
>
>>> NB I find the reindentation resulting in `push_reload' awful, just as I
>>> do either version of the massive logical expression involved. Perhaps we
>>> could factor these out into `static inline' functions sometime, and then
>>> have them split into individual returns within?
>> I'm generally hesitant to do a lot of changes to the reload code base
>> at this stage. The strategy rather is to move all remaining targets
>> over to LRA and then simply delete reload :-)
>>
>> Given that you're modernizing the vax target, I'm wondering if you
>> shouldn't rather go all the way and move it over to LRA as well,
>> then you wouldn't be affected by any remaining reload deficiencies.
>> (The major hurdle so far was that LRA doesn't support CC0, but it
>> looks like you're removing that anyway ...)
> I considered moving to LRA, but decided to make one step at a time,
> especially given the number of issues the VAX port has been suffering
> from. For example there are cases evident from regression test failures
> where new pseudos are created past-reload. That would require tracking
> down, and I think switching to LRA would best be made with cleaner test
> results so as not to introduce another variable into the picture.
>
> So I would consider it GCC 12 material, so that we have an actual release
> with the VAX port converted to MODE_CC, but still using reload. I think
> it could make some backports easier too if NetBSD people wanted to do it.
That was my plan on H8 as well (switch to LRA next cycle). I am aware
of one reload issue that the move away from cc0 triggers, but I'm
ignoring it for now.
Jeff
