[llvm-dev] [GSoC] Improve parallelism-aware analyses and optimizations

[Johannes Doerfert via llvm-dev]

On 3/25/20 5:59 PM, Nader Al Awar wrote:
 > Hi Johannes,
 >
 > Based on my understanding, we need a function that returns a set of
 > pointers to Functions that are either transitively called or call
 > other functions transitively. Is that correct?

Given a set of Functions F1,F2,..., collect all functions P1,P2,.., that
transitively call any F and all functions C1,C2,..., that are
transitively called by any F. We have the call graph to help us with
that!


 > Also, when you say that the computation of the ModuleSlice has to be 
generic,
 > do you mean that the container of the Function pointers is generic? 
As in it
 > could be a SetVector or SmallPtrSet?

No. What I meant is that we should have the logic in a separate helper
function we can reuse. It should not be tied to "OpenMP".


 > Or are you saying that the condition that decides whether a Function 
belongs
 > to the returned slice is generic? If the condition is generic, I'm
 > guessing the best way to do that is by passing a lambda?

I'm not sure we need that just yet.


 > Also, would the best place to define this function be inside a
 > container class?

For now, just put it as a static helper at the top of OpenMPOpt. It
takes the initial functions, the container, and the call graph. Since we
might need it for the old and new pass manager call graph we might need
to wrap parts of the call graph in a lambda. E.g., a way to iterate all
call sites in a given function.

Feel free to start with a simple approach and we go from there. Also
keep asking questions :)

Cheers,
   Johannes


 > Thanks,
 > Nader Al Awar
 >
 > On Tue, Mar 24, 2020 at 6:29 PM Johannes Doerfert
 > <johannesdoerfert at gmail.com> wrote:
 >>
 >>
 >> Hi Nader,
 >>
 >> I think it is cool that you are interested and it's good you looked
 >> through the background already.
 >>
 >> There is no strict requirement to complete tasks before an official
 >> proposal but we always encourage people to get in touch with the list
 >> first, which you did, and also get used to the development process we
 >> have. That is often done best with a simple task.
 >>
 >> One thing you could look at is the TODO in OpenMPOpt.cpp:511 and again
 >> 557. The problem is that a call graph SCC pass is only allowed
 >> (=supposed to) look the given SCC, the transitive callers, and
 >> everything transitively called. I called this set of functions a
 >> "ModuleSlice". While we don't strictly need a better ModuleSlice set in
 >> OpenMPOpt just yet, we will soon. Also, the computation of the
 >> ModuleSlice set for a given set of functions should be generic as we
 >> need exactly the same logic in other CGSCC passes, e.g. the Attributor.
 >> There it should directly show improved behavior and resolve various
 >> FIXMEs in the tests.
 >>
 >> Does this make sense? Feel free to reply with questions.
 >>
 >> Cheers,
 >>    Johannes
 >>
 >> P.S.
 >>    Check the llvm documentation on how to contribute, how to use
 >>    phabricator, and coding style ;)
 >>
 >>
 >> On 3/24/20 10:12 AM, Nader Al Awar via llvm-dev wrote:
 >>  > Hello,
 >>  >
 >>  > My name is Nader Al Awar, and I am a master's student at UT Austin.
 >>  > I’m interested in working on the "Improve parallelism-aware analyses
 >>  > and optimizations" project as part of GSoC.
 >>  >
 >>  > I looked at the relevant talks papers and I believe that I would be a
 >>  > good fit. Most of my background is in software engineering and
 >>  > testing, but recently my research has focused on applying HPC to 
those
 >>  > areas, specifically using CUDA. Besides that, most of my 
experience is
 >>  > in C++ and I am also familiar with openMP. I have always been
 >>  > interested in compiler optimization and would like to get a chance to
 >>  > work in that field.
 >>  >
 >>  > Are there any tasks I need to complete before I can submit an
 >> official proposal?
 >>  >
 >>  > PS: I am resending this email because I accidentally sent it as HTML
 >> before
 >>  >
 >>  > Sincerely,
 >>  > Nader Al Awar
 >>  > _______________________________________________
 >>  > LLVM Developers mailing list
 >>  > llvm-dev at lists.llvm.org
 >>  > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
 >>