Menu
▾
▴
Re: [Chapel-gsoc] GSoC 2018 Compiling Chapel with LLVM/Polly
|
From: SAHIL G. Y. <cs1...@ii...> - 2018-03-24 17:24:32
|
Hi all, Here <https://docs.google.com/document/d/1qI2qxAVy22B8ck30LjZfNDO848t-RNLIqOmdW3lvAEY/edit> is the link to my project proposal. I am looking forward towards receiving your feedback. On Fri, Mar 23, 2018 at 2:50 AM Michael Ferguson <mfe...@cr...> wrote: > Hi - > > Should the Polly project choose to accept one of the applications for the > Chapel+Polly GSoC project, I'm happy to help mentor it. > I think it makes sense to work on a Polly bug to demonstrate your ability. > > Cheers, > > -michael > > 2018-03-22 15:57 GMT-05:00 'SAHIL GIRISH YERAWAR' via Polly > Development <pol...@go...>: > > > > Hi all, > > Thanks for the reply! > > > > I am really excited to take up this project as a part of this year's > GSoC and would like to confirm the mentors for this project to discuss > further possible ideas about this project. > > > > As Polly's GSoC page suggested you both as possible mentors, I would > like to ask both of you if you are interested to mentor for this project. > Others are also welcome to take part in this mentorship process. > > Depends on what other proposals there are. Tobias and me are currently > the people with expertise in Polly in the mentor list. Since each of > us can only mentor a limited number of projects, we may need to bring > in other mentors as well. > > > > > > PS: I have successfully installed Chapel and LLVM+Polly on my system > and for some simple loops (ones suggested by Michael Ferguson) it is giving > missed optimization remarks. > > Which are? > > For you to know: We expect students to do a little work on their > project (Polly or Chapel) so we know that they are capable of what > they are proposing. > Would you look into https://bugs.llvm.org/show_bug.cgi?id=36640 ? (You > can do something else if you like). > > We also would like to see your proposal's draft in advance to ensure > we don't have to reject it because of formalities. Please see > > https://docs.google.com/document/d/1Zgu22S347TE6xLtnMbQR_R663J2lgpUrfOG3GLhZLe0/edit?usp=sharing > > Michael > > > > > > On Fri, Mar 23, 2018 at 2:18 AM Michael Ferguson <mfe...@cr...> > wrote: > >> > >> Hi - > >> > >> Indeed, it makes sense to eventually have a flag to activate Polly > >> integration. I suspect --mllvm -polly (note the extra dash vs the > >> clang version) can work for this as a start. > >> > >> Let's talk more about what other flags we want once we have > >> Polly doing something useful with IR from the Chapel compiler. > >> > >> Thanks, > >> > >> -michael > >> > >> Hi think it is a good idea, clang sort-of also has this (-mllvm > >> -polly). Unless users would want to unconditionally enable polly > >> (unfortunately there are cases where the code becomes slower > with > >> Polly), we will need such a switch. > >> > >> However, I don't know whether the syntax is concistent with the > other > >> chpl option, Michael F. should know this. > >> > >> Michael > >> > >> > >> 2018-03-20 16:21 GMT-05:00 SAHIL GIRISH YERAWAR < > cs1...@ii...>: > >> > Hi > >> > > >> > For this Chapel project, whose main aim is to correctly > identify Chapel's > >> > loops as SCoP's, I am also thinking developing a new flag > "--polly" as an > >> > option for chapel which can enable Polly-based optimizations > on demand. This > >> > will be a single module whose end result would be optimized > binary. > >> > > >> > I would like to have some feedback on this feature in terms > of its > >> > applicability. > >> > > >> > Regards > >> > Sahil Yerawar > >> > > >> > > >> > On Tue, Mar 20, 2018 at 10:10 PM Michael Kruse < > ll...@me...> wrote: > >> >> > >> >> 2018-03-20 17:27 GMT+01:00 'SAHIL GIRISH YERAWAR' via Polly > >> >> Development <pol...@go...>: > >> >> > Sir, > >> >> > > >> >> > Thanks for the response. Michael Ferguson (cc'ed in this > mail) has > >> >> > already > >> >> > given a way to generate LLVM-IR's from chapel programs.It > involves > >> >> > converting chapel code to C code and saving it in a > directory(using > >> >> > --savec) > >> >> > and applying --llvm flag on top of it. > >> >> > >> >> Yes, I've seen it after I sent my response. > >> >> > >> >> > > >> >> > On other hand, I have another doubt in Polly. While going > through > >> >> > Scopdetection.cpp, the initial description mentioned > "canonical > >> >> > subregions > >> >> > of a region in SCoP". What is meant by the word > "canonical" in > >> >> > "canonical > >> >> > subregion"? > >> >> > >> >> "Canonical" in this could be interpreted as "Normalized". > Meaning that > >> >> the start and end of a scop region is unique according to > some > >> >> definition. In this case, this is the result of the > RegionInfo pass. > >> >> See <llvm>/include/llvm/Analysis/RegionInfo.h to see a > description of > >> >> what "canonical" means. > >> >> > >> >> ScopDetection then enlarges the canonical region, which may > not > >> >> correspond to any region computed by RegionInfo. > >> >> > >> >> > > >> >> > Regards > >> >> > Sahil Yerawar > >> >> > > >> >> > > >> >> > On other hand, I do have some doubts > >> >> > >> >> What other questions do you have? > >> >> > >> >> Michael > >> >> > >> >> > >> >> > > >> >> > On Mon, Mar 19, 2018 at 9:57 PM Michael Kruse < > ll...@me...> > >> >> > wrote: > >> >> >> > >> >> >> 2018-03-19 14:52 GMT+01:00 SAHIL GIRISH YERAWAR > >> >> >> <cs1...@ii...>: > >> >> >> > Hi, > >> >> >> > > >> >> >> > I have generated IR files for test10d() and test80d() > functions > >> >> >> > present > >> >> >> > in > >> >> >> > the attached chpl code. > >> >> >> > > >> >> >> > On running opt on it, it gives a parser error of the > form "base > >> >> >> > element > >> >> >> > of > >> >> >> > getelementptr must be sized" at lines 155 and 141 of > test10d() and > >> >> >> > test80d() > >> >> >> > respectively. These files are attached with this mail. > >> >> >> > > >> >> >> > I am of the opinion that since these aggregate types > are initially > >> >> >> > defined > >> >> >> > outside the scope of the functions, we need to work on > IR of the > >> >> >> > whole > >> >> >> > program itself. > >> >> >> > >> >> >> I agree on your assessment. Metadata is also missing. > Only LLVM > >> >> >> "modules" can be exported into .ll files and imported > again. Single > >> >> >> functions can be just "dumps" (unless it is module where > all other > >> >> >> functions have been removed). Modules typically start > with e.g.: > >> >> >> > >> >> >> target datalayout = "..." > >> >> >> target triple = "x86_64-linux-gnu" > >> >> >> > >> >> >> > However, I am not able to find proper flags which can > enable > >> >> >> > dumping of whole program's IR. Is there any such > compiler flag which > >> >> >> > enables > >> >> >> > this? > >> >> >> > >> >> >> Have you tried removing the --llvm-print-ir=test10d > option? I don't > >> >> >> know which options the Chapel compiler supports, there > should be one > >> >> >> to exporte enitre modules. Is there a "chpl --help"? > >> >> >> > >> >> >> Michael > >> >> > > >> >> > -- > >> >> > Thanking you > >> >> > Sahil Yerawar > >> >> > Department of Computer Science > >> >> > IIT Hyderabad > >> >> > > >> >> > -- > >> >> > You received this message because you are subscribed to > the Google > >> >> > Groups > >> >> > "Polly Development" group. > >> >> > To unsubscribe from this group and stop receiving emails > from it, send > >> >> > an > >> >> > email to pol...@go.... > >> >> > For more options, visit https://groups.google.com/d/optout > . > >> > > >> > -- > >> > Thanking you > >> > Sahil Yerawar > >> > Department of Computer Science > >> > IIT Hyderabad > >> > >> > > -- > > Thanking you > > Sahil Yerawar > > Department of Computer Science > > IIT Hyderabad > > > > -- > > You received this message because you are subscribed to the Google > Groups "Polly Development" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to pol...@go.... > > For more options, visit https://groups.google.com/d/optout. > > > -- Thanking you Sahil Yerawar Department of Computer Science IIT Hyderabad |
