On Fri, 7 Sep 2018 10:30:30 +0200 Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote:
> On Thu, 6 Sep 2018 at 03:25, Jerry DeLisle <jvdeli...@charter.net> wrote: > > > > On 09/05/2018 07:57 AM, Bernhard Reutner-Fischer wrote: > > > Hi, > > > > > > The fortran frontend still uses stack-based handling of (symbol) names > > > with fixed-sized buffers. Furthermore these buffers often are too small > > > when dealing with F2003 identifiers which can be up to, including 63 > > > bytes long. > > > > > > Other frontends use the stringpool since many years. > > > This janitorial series is a first step towards using the stringpool in > > > the frontend. > > > Consequently this allows us to use pointer-comparison to see if two > > > given "names" are identical instead of doing lots and lots of string > > > comparisons. > > > > > > > > > Part 1 switches most of the fortran FE. An eventual part 2 would > > > continue to switch the few remaining stack-based identifier > > > manipulations to use the stringpool. My initial plan was to also see if > > > switching gfc_symtree from treap to a hash_map would bring us any > > > measurable benefit, but that, too, is left for an eventual part 2. > > > > > > Bootstrapped and regtested on x86_64-foo-linux. > > > > > > I'd appreciate if someone could double check for regressions on other > > > setups. Git branch: > > > https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > > > > > > > I am not so git savvy as I would like. If you could send me a single > > patch to trunk I will try to test on a FreeBSD system. It is usually a > > bit more picky than linux.. > > I've just encountered a regression in module writing, let me have a > looksie at that first so i don't waste your time. > > PS: You'd: > git clone git://gcc.gnu.org/git/gcc.git ~/src/gcc-9.0-stringpool > cd ~/src/gcc-9.0-stringpool > git checkout aldot/fortran-fe-stringpool > # this should output: > # Branch aldot/fortran-fe-stringpool set up to track remote branch > aldot/fortran-fe-stringpool from origin. > # if your git client is too old, then do it manually: > # git checkout -b aldot/fortran-fe-stringpool --track > origin/aldot/fortran-fe-stringpool > mkdir -p ~/obj/gcc-9.0-stringpool > cd !$ > ../../src/gcc-9.0-stringpool/configure --prefix /opt/..... && make > install && make -k check;# as usual > > I'll send you a full patch when i had a chance to track down the > module writing bug. IIRC i fixed the abovementioned bug and pushed it to the branch. Unfortunately the abovementioned personal git branch somehow was deleted in the meantime. Now i was about to rebase my local tree in the light of the upcoming GCC-11 release and i'm confronted with a couple of conflicts that stem from /me touching all these spots that are troublesome _and_ slow (due to gazillions of strcmp calls to match identifiers; Part of the .plan was to see if sacrificing a little bit of memory to maintain hash_map of identifier_pointers would pay off WRT way faster comparison -- pointer cmp versus strcmp as noted above. ISTR that's what other frontends do since decades and i think it would make sense for the fortran FE too). Iff there is any interest in eventually accepting abovementioned direction into the tree, either part1 only which has merity on his own - as you can see from recent asan induced tweaks to our identifier handling - or also part 2 which encompasses the endavour to speedup the actual matching of identifiers and hence speed up some small parts of the frontend then i'm willing to rebase the series. Of course if nobody thinks that the proposed direction is the right thing to do then i will happily delete the effort so far. Saves quite some of my sparetime. For posteriority, a previous series of part1 was archived here: https://gcc.gnu.org/pipermail/gcc-patches/2018-September/thread.html#506111 As can bee seen in the series and was in part explained in https://gcc.gnu.org/pipermail/gcc-patches/2018-September/506849.html this series changes module format a little bit. Specifically, several spots do (or did back then, at least) use NULL module names in certain situations in a non-obvious way (i wouldn't dare to say hackish for i do not remember the gory details offhand i admit). I believe i initially wrote the series even before submodules but AFAIR they did not interfere in any noticable way. Modules were misbehaving but submodules not, IIRC. The fact that i need to change the module content was the main reason why i did not apply the batch back then, even if Jerry was kind enough to OK the submission as is, as you can see in above thread. So i again reach out for consensus so to maybe get this improvement into GCC-12 iff deemed appropriate and useful. Or i'll just drop it for good. thanks,
