Adds back support for generating cache barriers on systems that cannot properly handle the R10K's speculative execution capability. This is required for building kernels to run the IP28 Indigo2 Impact R10000 system and for development tests of an equivalent kernel for R10000 IP32 O2 systems.
Created attachment 161604 [details, diff] Add cache barrier support to gcc for mips R10K
FYI, this is for gcc-4.3.1 ebuild.
Has this been submitted upstream?
I believe this is scheduled to appear in gcc-4.4. I'll have to check with the original patch's author, but the last e-mails I got him from pointed at this.
When this has been accepted by upstream please let me know. Thanks
We actually had this in gcc before, currently in 4.1.2. This is just an update patch to put it into 4.3, since we skipped 4.2 entirely. Or are the rules different, and all patches now have to be in upstream? Waiting till 4.4, possibly even 4.5 will take far too long.
I'll just respond to this one instead of to both. We are trying to keep GCC as close to what upstream provides as possible. Maintaining our own patches that they won't be accepting makes it more difficult to get upstream support. So we really like upstream to have accepted the patches before applying them ourselves.
These patches do not touch anything outside of gcc/config/mips and are required for IP28 and IP32 R10K support in Gentoo, which is experimental but still supported. We could really use 4.3 because frankly 4.1 is brutal on mips.
TBH, I thought about just adding them and uploading a newer gcc for mips only, but I felt that'd cause too much confusion, and seeing as we completely skipped an entire gcc major revision, felt it's be better to file a bug and work through the processes (I am on toolchain, btw). For Bug #233230, I sent the patch upstream, but there's no telling when it'll get queued for inclusion. It's definitely impossible for it to ever make it into 4.3, and I don't know if the new features window for 4.4 has closed yet. It may be another two years before this sees upstream light-of-day. For this bug, I sent a query to get confirmwation on whether the cache barriers patch is queued for 4.4. It too, is too invasive for 4.3, but if it's in the queue for 4.4, then that will solve one problem. Preferably, this patch can wait a little bit, though. While the conversion to 4.3 wasn't too difficult, I haven't had a chance to actually build a kernel for it yet, so I don't know if this patch will work 100%. But the R10K scheduling patch has been pretty static since I converted it to the DFA architecture in the early gcc-4.0.x days. We previously had it in all the gcc-3.x ebuilds from 3.2 on upwards. It's pretty stable.
4.4 is still in stage one but i get the impression that it was only so because some major branches like the tuples and stack branches were not ready. they were merged this week so i'm guessing stage two is imminent. but there has been a lot of mips related work going into 4.4 and also into binutils lately so it might be a good time for getting this in. Richard Sandiford and Daniel Jacobowitz appear to be driving most of it so it may be worth it to contact them and see if they can help.
we've been including this patch forever when Joshua gets happy with it. if he's happy with this version, we can toss it in as 90_all_mips-add-march-r10k.patch again.
Created attachment 169534 [details, diff] R10K Cache Barriers patch from gcc-4.4 The attached patch is a backport from GCC SVN. Rewritten by Richard Sandiford, it'll be in the upcoming gcc-4.4 release. SVN Revision is here: http://gcc.gnu.org/viewcvs?view=rev&revision=140055
FYI, tested against gcc-4.3.2, so I think it's best that this patch gets added to that version and that version only. I don't trust 4.3.1 right now until I pin down the cause of my glibc woes.
Forgot to note, the attached patch is actually a combination of GCC SVN Revision 136738 and 140055 (the cache barriers patch). 136738 is a dependency for 140055, but to save, I combined both into a single patch. http://gcc.gnu.org/viewcvs?view=rev&revision=136738
In the newest patch tarball, thanks for getting these pushed upstream.
