Can help with task of language frontend cleanup

Can help with task of language frontend cleanup

[pawel k.]

Hello,
Not sure which list is right. I have ideas for code improvement for gcc.

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.

It doesnt seem very difficult just quite laborious. If anyone is interested
in such improvement please authorize me to branch off. Ill drop my changes
there. Will need help with extending build system/configure/makefiles.

Idea2 multiple targets in single binary choosable at runtime.

With those two tasks we will gains some modularity maintainability better
architecture and more on par with llvm/clang features.

Ps. Gcc target list is great. Love and respect it.

Best regards,
Pawel Kunio

Re: Can help with task of language frontend cleanup

[Jonathan Wakely]

On Thu, 25 Mar 2021 at 09:43, pawel k. via Gcc-help
<gcc-help@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.

Re: Can help with task of language frontend cleanup

[Jakub Jelinek]

On Thu, Mar 25, 2021 at 12:06:08PM +0000, Jonathan Wakely via Gcc wrote:
> 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?

I don't see an advantage to have different FEs in the same binary, and a lot
of things aren't done through language hooks, but just calling specific
functions from the FE (both when the generic code does that and when e.g.
c-family code calls functions implemented separately by the FEs).

Having some binary do the cross-compilation would be nice e.g. for
offloading that we wouldn't need to jump through LTO bytecode saving and
loading to switch targets between separate processes, but I'm afraid
achieving that is far from the scope of GSoC (orders of magnitude).  While
we have target hooks, they cover only part of the backend interfaces.  A lot
is done e.g. through macros the targets define, and while some of them could
be easily replaced by target hooks (and many have been in the past), some
macros really should ideally never be target hooks, e.g. making
BITS_PER_UNIT not a macro but a member of target hooks (or even worse a
call) would slow down the compiler a lot.  Another difficult area is that
we have a lot of generated inline functions, macros and functions emitted
by the gen* tools, that is again specific for a particular target, so
merging it from multiple targets would be a lot of work and again risks of
slowing the compiler down.  Then is the option processing code, different
targets have different target specific options, we have generators for the
option handling, but for a single binary to support multiple targets we'd
need to mark the option tables/macros etc. as specific to different targets,
making them coexist and find out what to do on the command line (e.g. if
the target selection option doesn't come first on the command line, how to
do the target specific option processing when the code doesn't know for
which target it will be; e.g. some targets could have option that takes a
required argument but another target could have option with the same name
that doesn't take an argument).

	Jakub

Re: Can help with task of language frontend cleanup

[pawel k.]

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.gcc@gmail.com>
napisał:

> On Thu, 25 Mar 2021 at 09:43, pawel k. via Gcc-help
> <gcc-help@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.
>