Hi everyone!
Today is the official “pencils down” day for GSoC and I wrote a report describing what results I’ve achieved since my last report in July:
http://flang-gsoc.blogspot.ie/2013/09/end-of-gsoc-report.html
Thanks for this GSoC LLVM!
Wow, fantastic results! Great work!
cheers,
–renato
I'd like to publicly congratulate Alex for his excellent work this summer! He worked diligently throughout the entire period, and he quite-successfully tackled an ambitious project. As a result, we now have a Fortran frontend for LLVM capable of compiling real packages (BLAS, LAPACK, etc.), and correctly executing the test suites for those packages. Thanks to Alex, and to Google, we now have a solid foundation from which to build a community-developed LLVM Fortran frontend.
https://github.com/hyp/flang
-Hal
Congratulations Alex!
It would be nice to have a flang buildbot. Unfortunately, I don't
have time to write the necessary zorg magic to check out/compile
flang. But I would be happy to host a buildbot if somebody writes the
necessary zorg code.
Dmitri
Wow, this is really fantastic work. I’m surprised and impressed by how much progress you made.
Can you comment more about Pathscale’s plans, and why they don’t want to release the code?
-Chris
Initially the code will continue to be developed privately, but there's a big ?<question mark> and sticky note to look at what makes best sense - It's a conservative approach, but that's how it is for now.
We're open to feedback - both on and off list...
Hi everyone!
Today is the official "pencils down" day for GSoC and I wrote a report describing what results I've achieved since my last report in July:
Flang GSoC progress blog: End of GSoC report
Thanks for this GSoC LLVM!
Wow, this is really fantastic work. I'm surprised and impressed by how much progress you made.
Can you comment more about Pathscale's plans, and why they don't want to release the code?
Initially the code will continue to be developed privately, but there's a big ?<question mark> and sticky note to look at what makes best sense - It's a conservative approach, but that's how it is for now.
Do you have specific goals here? This is not a great way to foster the community and get contributions to the project.
It's along the same lines as to why OpenCL by most vendors is developed privately..... (I realize this has gotten a lot more attention and better in the past 1-2 years)
… you're absolutely right, that is a great analogy. I think that the way OpenCL was developed, specifically its lack of open source engagement, is universally considered to be a failure that should not be repeated. Look at all the vendors who independently had to invent the same functionality, then clashed when they each tried to merge it back to mainline clang.
I'm not sure what business advantage you think that a fortran frontend would give you, but you should carefully consider what you think you're achieving.
-Chris
Ok - thanks for that insightful heads up. It's not really Apples vs Apples though. OpenCL has multiple companies working on it, but for Fortran - who are "all the vendors"... (Fortran has been around *a lot* longer - it's not like new players are popping up every month)
Given the nature of path64, I think it would be nice to keep all parsing
related parts and all semantic analysis open. It would also be nice to
keep functional tests for the code generation as open as possible, even
if might not fit into a "main" repository due to testing executable
code. The goal would be to allow Pathscale to what they are doing on the
backend without having a strongly divergating frontend, which is likely
not in the interest of anyone.
I am aware that flang in the current form shared code with clang in
non-trivial ways and it certainly will require some effort to refactor
the code on either side for allowing flang to become an integrated LLVM
project. Who's interested with dealing with that on the Clang side? I
hope Alex is willing to work on the flang side?
Joerg
I'm not sure what business advantage you think that a fortran frontend would give you, but you should carefully consider what you think you're achieving.
Ok - thanks for that insightful heads up. It's not really Apples vs Apples though. OpenCL has multiple companies working on it, but for Fortran - who are "all the vendors"... (Fortran has been around *a lot* longer - it's not like new players are popping up every month)
---------
In the past couple of years - I've been an advocate of a Fortran-clang front-end, but until recently it wasn't very active. No magic community formed and really who cares? (devils advocate hat on) Besides ANL - who will the potential users be? (Honest question to anyone reading this)
I think you have some fundamental misunderstandings of how open source software works in practice. You don't magically get dozens of contributors contributing patches the day you open your doors.
LLDB, for example, took over a year and a half of development in public before the community really started growing around it. Fostering an open source community is a lot of work, and a long term play.
On a more technical note - flang is not upstream friendly "right now" (imho). The technical issues with integrating it cleanly into clang upstream are and will be worked out. I think if we do move to an open development model we need to be working on clang master. This will get the project more exposure as well make it easier for people to test.
Fortran is totally non-c-family - It's like trying to add Python, Java or COBAL - It gets even more complicated with things like module formats, CAF and arrays. When we try to upstream our patches - who will review them? Will it be like OpenMP where things get bottlenecked waiting on reviews for (months/weeks). (This may tie into who will the users be and the overall general community interest)
I'm fine with flang either becoming part of LLVM in time, or being separate. I'm fine with you guys reviewing your own patches, etc. I'm just advocating that you keep the frontend public.
-Chris
> >
> >
> >>Hi everyone!
> >>
> >>Today is the official "pencils down" day for GSoC and I wrote a
> >>report describing what results I've achieved since my last
> >>report in July:
> >>
> >>http://flang-gsoc.blogspot.ie/2013/09/end-of-gsoc-report.html
> >>
> >>Thanks for this GSoC LLVM!
> >
> >Wow, this is really fantastic work. I'm surprised and impressed
> >by how much progress you made.
> >
> >Can you comment more about Pathscale's plans, and why they don't
> >want to release the code?
> Initially the code will continue to be developed privately, but
> there's a big ?<question mark> and sticky note to look at what
> makes
> best sense - It's a conservative approach, but that's how it is for
> now.Given the nature of path64, I think it would be nice to keep all
parsing
related parts and all semantic analysis open. It would also be nice
to
keep functional tests for the code generation as open as possible,
even
if might not fit into a "main" repository due to testing executable
code. The goal would be to allow Pathscale to what they are doing on
the
backend without having a strongly divergating frontend, which is
likely
not in the interest of anyone.I am aware that flang in the current form shared code with clang in
non-trivial ways and it certainly will require some effort to
refactor
the code on either side for allowing flang to become an integrated
LLVM
project. Who's interested with dealing with that on the Clang side? I
hope Alex is willing to work on the flang side?
Alex may be otherwise captured for the time being, but I plan on working on this over the next few months. As I've mentioned in the past, I'd like the two projects to share the driver (or at least the driver infrastructure), and I'd like to give flang a C preprocessor based on Clang's. Regarding other code sharing, we'll need to do some serious thinking about what parts should actually be shared in the long run vs. what's acting as a crutch right now.
-Hal
Thanks everyone!
I think that by reusing clang’s code flang will benefit a lot. Clang’s type system and declaration nodes will be especially useful because of CAF. And, of course, clang’s tool interfaces, frontend and driver will come in handy. But at the same time Fortran isn’t C, so I don’t expect that clang will incorporate any features from flang or accommodate any needs that flang might have. But perhaps clang could be made more flexible so that it would encourage other frontends to reuse its valuable infrastructure. I don’t really have any ideas or suggestions how that can be done at the moment, but I hope that somebody else might.
Cheers,
Alex