This is the mail archive of the 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: GSoc-2015: Modular GCC

On 03/06/15 18:22, Mikhail Maltsev wrote:
05.03.2015 18:46, Jeff Law wrote:
Certainly still useful, the trick is finding a hunk of that work that
can be tackled via GSoc.


Though I'm not participating in GSoC, I would be glad to get involved in
GCC development.

Could you please give some comments on current status of the following part:

"Before GCC can be modularized properly, it is necessary to make clear
what interfaces and declarations are actually needed in each source
file. This will, no doubt, be a huge job. It is unclear at the moment
whether there are tools available that could help (Dehydra perhaps, or a
dedicated plugin, or Ctags? Or turn this patch into a proper plugin?
Maybe create a symbols database and identify dependencies to break?)."
It's an ongoing project. Two active sub-projects are pulling apart the headers so that we can identify routines from the front-ends that are being used outside the front-ends and deferring of debugging output.

The intermediate goal of the first of those projects is the ability to start extracting tree types out of the gimple and backends.

Other sub-projects that have received a lot of attention over the last year are adding a c++ class hierarchy to part of gimple and RTL. One potentially easy project there would be to take David Malcolm's work to turn the RTL EXPR & INSN lists into standard C++ forward lists. One that's harder would be pushing the rtx_insn * class further. Basically most of the places where we have a as-a cast between rtx_insn * and an rtx is a good candidate for removal and further propagation of rtx_insn * types.


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