On Wed, Mar 21, 2012 at 7:57 PM, Richard Guenther <richard.guent...@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
