[LLVMdev] GSoC project questions.

Matthieu Brucher matthieu.brucher at gmail.com
Wed Apr 24 08:12:26 PDT 2013


Hi Alex,

You may want to check the later versions of the standard also to check if
some of your proposal is not deprecated there. The most important thing in
the Fortran standard is the array support and it is a big task by itself.
In my opinion, the I/O part is not the most important thing yet it is an
enormous task. Usually, the Fortran routines are used externally in other
computation and I/O is done through other and more efficient layers.

I hope your proposal will be accepted and I'm looking forward to seeing the
result of your work.

Cheers,

Matthieu


2013/4/24 Alex L <arphaman at gmail.com>

> Hi again.
>
> I've though more about the full standard being too ambitious, and now I
> fully agree with that. So I had a go at choosing the useful subset of
> Fortran on which I would like to work on - my update proposal can be viewed
> at https://gist.github.com/hyp/5434845 .
> Focusing on less should also improve my productivity and lead to a better
> summer of code project by drastically reducing the pressure :)
>
>
> 2013/4/22 Alex L <arphaman at gmail.com>
>
>> Thanks for the responses!
>>
>>
>>> I might be wrong (I'd love to be wrong here!) but I think this is a bit
>>> too ambitious
>>>
>>  You might be right about it being too ambitious, it would certainly be
>> wise to aim for less. A more polished, but less broad product is definitely
>> better than a buggy standard compliant one, and I think that it would go
>> better with the general philosophy of GSoC. I will take this fact into
>> consideration for the revised proposal.
>>
>>
>> Also, in your proposal, it looks as though you're not writing tests until
>>> the end; tests need to be written as soon as the features are testable.
>>>
>>  That's kind of true, but I actually planned on writing tests during
>> feature development, it's just that these tests wouldn't cover everything
>> and should be expanded and tested fully towards the end of GSoC. I should
>> definitely mention that in my plan.
>>
>>  As for the tooling support, I guess that it wouldn't hurt to take the
>> fact that tools should be integrated with flang in the future into account
>> during the development. I will take a look on how clang and various tools
>> for it operate.
>>
>>
>> 2013/4/22 Hal Finkel <hfinkel at anl.gov>
>>
>>> ----- Original Message -----
>>> > From: "Dmitri Gribenko" <gribozavr at gmail.com>
>>> > To: "Alex L" <arphaman at gmail.com>
>>> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>>> > Sent: Monday, April 22, 2013 9:00:51 AM
>>> > Subject: Re: [LLVMdev] GSoC project questions.
>>> >
>>> > On Mon, Apr 22, 2013 at 4:30 PM, Alex L <arphaman at gmail.com> wrote:
>>> > > Thanks for your support.
>>> > > I wrote my draft GSoC proposal, it can be viewed here -
>>> > > https://gist.github.com/hyp/5434845
>>> > > Please read it and tell me what you think. Any criticisms or
>>> > > suggestions are
>>> > > welcome!
>>> >
>>> > Hello Alex,
>>> >
>>> > > I plan to make flang a fully featured frontend which fully supports
>>> > > Fortran 77
>>> >
>>> > I might be wrong (I'd love to be wrong here!) but I think this is a
>>> > bit too ambitious.  Given that you have to write tests *as you
>>> > implement the features*, handle corner cases (and one has to actually
>>> > discover corner cases from the standard, if one is not familiar with
>>> > Fortran) and produce diagnostics for invalid code, I don't think it
>>> > is
>>> > possible to implement all of the frontend + codegen within 12 weeks.
>>>
>>> Alex, I agree with Dmitri, I think that the proposal sounds a little too
>>> ambitious. Maybe everything will go smoothly and you'll be able to
>>> accomplish everything that you'd like, but we should plan for less. I favor
>>> identifying a useful subset (such as that needed for BLAS) and focusing on
>>> doing a really good job on that subset rather than trying to get full
>>> feature coverage. In my experience, coding tests and high-quality
>>> warning/error messages takes more time than coding the feature itself.
>>> Also, in your proposal, it looks as though you're not writing tests until
>>> the end; tests need to be written as soon as the features are testable.
>>>
>>> Regarding motivation, I would also like to bring the same kind of
>>> "tooling" (analysis and transformation) support available in Clang to
>>> Fortran. Not that this specifically impacts your project, but I think is an
>>> important part of the longer-term motivation for developing an LLVM Fortran
>>> frontend.
>>>
>>> I am glad that you're excited about working on this project!
>>>
>>>  -Hal
>>>
>>> >
>>> > Dmitri
>>> >
>>> > --
>>> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> >
>>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Information System Engineer, Ph.D.
Blog: http://matt.eifelle.com
LinkedIn: http://www.linkedin.com/in/matthieubrucher
Music band: http://liliejay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130424/b082bc23/attachment.html>


More information about the llvm-dev mailing list