Proposal: New Layer Maybe

[Philip Herron <redbrain at gcc dot gnu dot org>]

Hey all

I've been quietly spending the last years working on my
python-front-end in the background. And over the last few years always
been thinking that gcc could be simpler for front-end-developers. I am
just going to post up this simple high-level proposal just to gauge
the opinion of the gods that are GCC developers as i don't really want
to start working on something in a certain way in vain.

1 - How about an _optional_ library for front-ends, and some
generators: The library say libgcchelper could be optionally used in
the front-end code so developers could have a simpler higher-level api
(something akin to Kaleidoscope from llvm
http://llvm.org/docs/tutorial/LangImpl3.html) to generate code ready
for GCC. So over all it will be a high level IL which gets lowered to
GENERIC then we call gcc middle-end as normal. It could also provide
some generators to build a config.lang/lang.specs and your compiler
driver and the necessary boiler-plate code like langhooks. This could
work well so existing front-ends can use their code as usual and new
front-ends could use the generates to get the boiler plate code done
for them and then able to use GENERIC if they wish. But comes with the
cost of extra code to maintain which probably won't get picked up. in
the existing front-ends.

---

2- Another way to go is, implementing these generators and also adding
more code to the existing GENERIC api to make things simpler and maybe
some more error handling to GENERIC. By make things simpler i would
mean making new constructs like:

Function *F = Function::Create(FT, Function::ExternalLinkage, Name, TheModule);
...
BasicBlock *BB = BasicBlock::Create(getGlobalContext(), "entry", TheFunction);

Instead of the mountain of different ways you can make functions at
the moment. I think what makes GENERIC is so confusing is BIND_EXPR's
to implement blocks of code. As well as SUB/SUPER context's etc. Feels
very abstract talking about code in this way without knowing the
internals very well. Having a builder class like llvm to handle a lot
of the complicated fiddly trickery pokery to get things working.

But this is difficult because the tree api code is pretty much black
magic to me most of the time. But in the end probably the ideal
solution. I think with the move to c++ is probably going to get much
simpler with time.

---

This probably looks more like a brain dump but i think i want to work
on making something better in gcc and i think i can do something here
some opinions or discussion would be cool.

--Phil