This is the mail archive of the
mailing list for the GCC project.
Re: GSoc-2015: Modular GCC
- From: Jeff Law <law at redhat dot com>
- To: Mikhail Maltsev <maltsevm at gmail dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Sat, 07 Mar 2015 08:41:31 -0700
- Subject: Re: GSoc-2015: Modular GCC
- Authentication-results: sourceware.org; auth=none
- References: <CAA_ASpVFs7LXS4Pw1Mxo5VCxtEncvYXjYgnULGoRAWnbM3PkYw at mail dot gmail dot com> <54F87A48 dot 6070803 at redhat dot com> <54FA52CD dot 2080003 at gmail dot com>
On 03/06/15 18:22, Mikhail Maltsev wrote:
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.
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
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?)."
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