This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 5 & modularity


On Wed, Mar 21, 2012 at 7:57 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:

> Indeed. ?There is also different module hierarchies that overlap. ?For
> example ILs used in the different parts of the compiler.
>
> I think Basile is mostly confused about what files belong to what module,
> a question with not a single answer per file. ?It's been suggested before,
> but moving files into subdirectories might help here, at least for those
> which have a clearly defined module. ?The C frontend is one obvious
> example, generator programs for machine descriptions another,
> RTL optimization passes are harder, GIMPLE/SSA optimization
> passes are somewhat hard, ... there is not always a good directory
> to put things in. ?For example I absolutely hate the suggested gimple/
>
> Richard.

I see all the IL as storage/modules.  That transfer data between modules.

Breaking into modules does not mean a module cannot be dependant on a
different one.

So we could have a stack of modules dependant on particular IL module.

So Generic IL, Gimple IL, RTL IL would have modules in there own right
containing the code shared between optimisers and the like.

SSA processing of Gimple if the functions it using is used by nothing
else its SSA code.

Taking what gcc is and making into modules is just takes obeying a few
simple rules.

1 imports into your section have to come from other modules not lossy
shared files.(current confusion is lossy shared files)
2 there is no such thing as grey.  If a file is shared between two
modules it must be in a third module.   If file exists in both modules
you have split incorrectly.

If there is a grey area you have broken into modules wrong.  Module
based code has no grey.  No grey equals less errors of person editing
a file they think is exclusive to some part that turns out to be
shared with another part so causing nasty failure.

Like Gimplification has to be dependant on two modules for C.  Generic
IL and Gimple IL.  Most diagrams currently try to put it either in
front end or middle end.  When in fact its the bridge module between
front end and back end and its accessing data from both sides.

Once you start breaking modules correctly.  SSA is simple its just SSA.

With correct modules knowing what you are going to ruin by touching a
file become simpler.

So yes there should be a gimple/ directory but it should only contain
the shared functions and the internal code those shared functions use
to drive the gimple IL.  Repeat the same for RTL and Simple.

If you have broken everything right you should basically be able to
pull off building all the modules as .so/.dll files bar the core
application and have application work.

There should be a single answer per file Richard Guenther.  It is
critical there is.  So you know what you are working on.

Of course there are going to be a few files as cutting starts where if
we do a detailed design straight up when cutting starts its going to
be o bugger we need to create another module here so the code base is
clean.

We have the basic overview.  The question is were to start cutting.
Cutting front end stuff that is obvious would be a very good starting
point.

I don't expect gcc hierarchies to be a nice clean shape.  But it
should be able to be made cleaner.  So if I want to adjust like a
front end I know I am adjusting just the front end not something else.
 Same with SSA that I am fixing a bug in SSA I know that the files I
am currently touching SSA only uses.

Finally I know if I am playing in any of the IL directories I am
playing with fire.

Of course with SSA it might have subdirectories under it for code
sections that can be edited without effecting everything.   This is
where breaking into modules is good you can see how much risk you are
taking.

Personally in my eyes it time to start cutting into directories and
shaping the code up to neat.  Remove the left over layout from prior
to IL being used a lot inside gcc.

Basically we have the overview roughly how the code should look when
modules.  The final overview of the code as modules can only be done
after its chopped up into modules.   There is no requirement to chop
it all at once.  Trying to chop it all at once may not give enough
time to work out how to correctly cut any overlapping parts that turn
up.

So realistic goal should be a particular area chopped correctly.  Each
chop equals altering makefiles and moving files.  Slow can careful is
required when doing this is required.  Each chop could bring failure.
A chop per point release most likely would be too careful.

Basically Gcc 5=modular should a little of an extrema goal when we
have not made a decent percentage modular yet.   We have to get to
proper half or more modules before we really should set a goal like
this.  Once there is a clearer idea of the issues that will happen.

Peter Dolding


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]