Hi! On Sat, May 09, 2020 at 01:45:20PM +0700, Arseny Solokha wrote: > > LRA has been supported by the rs6000 port since 2013 (01b1efaa1439), > > and made the default (and only!) option in 2017 (7a5cbf29beb2). Ah, the > > latter was slightly after the split, I see. Did powerpcspe never work > > with LRA? > > It worked, but of course had its own issues: take PR79438 as one example (but > perhaps the problem there had not stemmed from RA at all), and I would > undoubtedly find more if I had enough time and knew they would be fixed. I > never > enabled LRA for our production code, though.
And it never was tested with it either... Not regularly anyway, and certainly the test results were not reported :-/ > So what I've been originally trying to say was that, while switching to LRA by > default would expose more problems and maybe wrong-code issues, removing > reload > as a fallback would put extra pressure on finding and fixing them. If the > switch > happened when SPE was just a part of rs6000 backend, some of the necessary > work > would be likely offset by people (and corporations!) behind the PowerPC > (sorry, > Segher), but reviving powerpcspe now means that all of that has to be done by > relatively small group of maintainers (or even by a single person) of a quite > niche target. Yeah... OTOH, LRA is more mature now then it was when PowerPC made the switch (or the many years before -- we finally made the switch when there were no performance or functionality regressions (we knew about) left). > PR19490 probably needs some consideration. Is there something left in rs6000 > backend that could be done prior to closing this one? -misel isn't an SPE option, and hasn't been only on CPUs that also have SPE since long (IBM CPUs have had it since POWER7). There are no options with "spe" in the name left, and I don't see any other options for SPE. > rs6000 backend still has some remnants of support of 854[08], namely, > instruction costs and some machine descriptions; is it on purpose? The idea is > that Power ISA on these cores is still supported, right? Yes, we support those CPUs just fine: select the correct instructions for them, and have a cost model and scheduling model. There is no real reason to make -mcpu=8540 no longer work. > >> PRs from the second group were filed by me, so if there's consensus to > >> close all > >> of them, the ones from this second group I can close myself. I don't have > >> the > >> right permissions to modify PRs reported by someone else, so I'd like to > >> ask a > >> volunteer to step up and close the ones from the first group. > >> > >> WDYT? > > > > I can do both, if you want, or just the first group? Your choice. > > > > But let's hear other opinions first. > > Thanks. I think I'll close the second group myself, as they constitute almost > half of the total amount. Okido, thanks! Segher
