Menu
▾
▴
Re: [Chapel-gsoc] GSoC 2018 Compiling Chapel with LLVM/Polly
|
From: SAHIL G. Y. <cs1...@ii...> - 2018-03-22 20:57:41
|
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. 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. 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 |
