Re: [Chapel-gsoc] GSoC 2018 Compiling Chapel with LLVM/Polly

[SAHIL G. Y. <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