Hello, Im sorry for posting to wrong group. Wasnt sure. Let me try to explain more clearly. Please forgive my nonnative english.
My idea is something like ideally single gcc.exe would be built deployed distributed runtests against per version per some/all frontends. We could think as of whether make frontends as shared objects or compiled statically. Id think id prefer statics for avoiding so mess. You could test all langs tests on single binary amongst other benefits. Also we wouldnt be spawning processes like crazy. Also build process would possibly get simpler less targets and so on. If we stuck with single frontend per binary wed still gain on cleaner interface to langhooks cleaner more consistent basic hooks use calling langhooks statically not through pointer (not sure hiw costly that is) possibly gaining better code locality around frontend inlining many basic hooks and enclosing them into frontend class. As an extra we could get better separation of frontend and middle part. Also adding new frontend would be cleaner process imho. In approach with multiple frontends per binary we could build one gcc and serve many langs possibly optimally building single exe for all langs. I mostly think here of easier testing across frontends. I updated tree processing and i want to check whether i didnt break any frontend on single gcc binary build. In thus approach build process would be simpler and running regressions could be done on single binary. If that still doesnt make any sense or is useless fair enough. I tried. If though multitarget approach would make any sense i could try to think about this approach but id need some help with modifying build process etc. Plus some research on building for all targets at once and so on. On this one im also thinking of avoiding text form of assembly (keeping it as option for debugging but using binary form or calls as default) and running gas internally not as an external process. If any of this makes any sense i can toy with it. Love the project and work you guys are doing. Would like to catch up with clang a bit and sync those two projects. Best regards, Pawel Kunio czw., 25.03.2021, 13:06 użytkownik Jonathan Wakely <jwakely....@gmail.com> napisał: > On Thu, 25 Mar 2021 at 09:43, pawel k. via Gcc-help > <gcc-h...@gcc.gnu.org> wrote: > > > > Hello, > > Not sure which list is right. I have ideas for code improvement for gcc. > > Please don't cross-post to gcc@ and gcc-help@, there are almost no > topics relevant to both. You're discussing GCC development, so gcc@ is > the right place. > > > > > Idea1 langhooks cleanup > > > > It basically involves clean up of lang hooks. Closing it in special > class. > > Might help to clean up massive defines etc spurious langhooks > declarations > > amongst others and removing some hooks from hooks.h/c and langhooks.h/c. > > Also in this solution wed gain some cputime by not calling langhooks via > > func pointers. > > > > Idea 1a multiple langhooks in single binary. Choosable in runtime. > > > > Ideally will allow compiling in multiple frontends in single binary and > > choosing in runtime which lang front to use. > > What would be the benefit? > > I can understand the advantage of a single binary that is a > cross-compiler for different targets (but it would be a huge task to > get GCC there). You wouldn't need multiple complete copies of GCC > installed to do cross-compilation if there was a --target option like > Clang's. But what's the benefit to users of a single binary for > different languages? The 'gcc' driver already exists and gives that > functionality, what would change with your proposal? > > > It doesnt seem very difficult just quite laborious. If anyone is > interested > > in such improvement please authorize me to branch off. > > I'm not sure what you mean by this, but you can just create a clone of > the Git repo and host it anywhere you want. >
