Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[David Malcolm]

On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote:
> Greetings All,
> 
> After doing some more research it seems that it may be time to
> remove 
> the garbage collector. I'm
> aware of the linkage to precompiled headers but even them I think
> its 
> time due to two reasons:
> 
> 1. The work related to multithreading gcc is working around the
> global 
> state of the collector which
> makes scaling less likely in terms of threads. In addition it is 
> causing   unnecessary compilations
> in terms of workarounds in this project.
> 
> 2. Memory usage may be decreased in certain passes due to being able
> to 
> implement memory allocation
> at a pass or per pass type level with more knowledge than a generic 
> garbage collector. I'm aware this
> is done for a lot of passes. However it  could be done for the other 
> passes that are linked currently to the
> garbage collector.
> 
> I'm not sure what memory allocation strategies we want to implement
> in 
> terms of replacing the garbage
> collector but I think its time.

Nick, you've sent various emails to this list suggesting big changes to
GCC's codebase (updating from C++98 to C++11 is another one that
springs to mind), but I believe you've yet to send the project an
actual patch for anything.

It's great that you want to help, and that you have ideas about the
high-level architecture of the project, but may I respectfully suggest
you start with something *much* smaller and more concrete?   There are
plenty of bugs in BZ that could use attention.

Hope this is constructive
David

> On another I'm looking into the issues with PHI nodes and operators
> as 
> to how to lock or decrease global
> state there as this seems to be the biggest complication when I've
> time. 
> In addition as Jeff stated we
> will also want to encapsulate SSA operands and other SSA related
> things 
> in a series of classes as part of
> this.
> 
> 
> Regards,
> Nick
>