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.
jeff
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.
Jeff
