This is the mail archive of the gcc-patches@gcc.gnu.org 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: treelang fix for rs6000 / treelang not proper front end


Tim Josling wrote:

Steven Bosscher wrote:



Remember that in an earlier discussion we had, I already _did_
offer you to make treelang 'proper' for a tree-ssa, and to
take over as a maintainer for that branch so that you would
only have to take care of mainline?  That was only a couple
of months ago, and you then said you didn't think it was
worth the effort.

Gr.
Steven



No I don't remember. What I seem to remember is a suggestion that I update it. I had a look at doing it but foundered on lack of documentation.

However if the offer is still open, I accept. This would certainly be a good step forward.

Sure, my offer still stands.


I am trying to update Fergus' patch to apply to the tree-ssa branch now (it needs some re-writing here and there). I will try to make it work with mainline as well if you like.

However, I would also like do discuss the future of treelang. It is a neat small front end, but the more I look at it, the less I like it in its current shape. IMHO if it is to be an example front end, then it should set a _good_ example. Actually I had already sort of given up on treelang.

I had started working on a treelang-like front end that conforms to the GCC conding style, targets GENERIC and is completely standalone. It produces a few non-GENERIC nodes in the parser to show how lowering the parse tree to GENERIC would work. I wanted it to follows sourcebuild.texi and frontend.texi to the letter.
(Unfortunately most if it got lost when my computer went up in flames...)


I also wanted the parser to build the parse tree using 'tree' and to build funtions as trees. I know you probably do not like parsing directly into 'tree', because treelang now shows how you can _not_ build trees and still interface with GCC, like most existing front ends (G77, G95, Ada, COBOL and a few others) actually do. But using trees from the start makes the front end much smaller. I used trees because I just wanted to see how it would look, but I can see why you choose differently. It is a matter of what you want to show with treelang.

So, what do we _want_ to show with treelang? What is the function of treelang within GCC and what implications does that have for its design?

Gr.
Steven



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