[llvm-dev] GSOC2020 LLVM project : Attributor framework

Wed Mar 18 17:48:13 PDT 2020

Hi Omar,

apologies for my delayed responses, crazy times.

You are looking for another task, correct?

You could look into this TODO in Attributor.cpp
// TODO: Improve the alignment of the loads.
Basically we need to determine the alignment of the pointers via the base and the offset.
To get the best alignment for the base we need to ask AAAlign for the base during the
initialize. We don't care about the value but we need to make sure it is computed. Then
we can use it where the TODO is.

Does this make sense?

Cheers,
  Johannes

________________________________________
From: Omar Ahmed <omarpiratee2010 at gmail.com>
Sent: Wednesday, March 18, 2020 13:24
To: Doerfert, Johannes
Subject: Re: GSOC2020 LLVM project : Attributor framework

Ping :)

On Fri, Mar 13, 2020 at 9:19 AM Omar Ahmed <omarpiratee2010 at gmail.com<mailto:omarpiratee2010 at gmail.com>> wrote:
Greetings Mr Johannes,

Regarding the no-forward-progress-gurantee attribute, i was interested in beginning to work on it, and I read the discussions on it carefully and you said in my review we should begin by invoking it as RFC on the mailing list to see where people stand in it, and i didn't find any discussions on it in the past days, so could i invoke it or we should wait on it for now?

Regarding gsoc2020 project attributes, i wanted to begin to prepare the proposal and i don't know what are the specific intended attributes to be done this summer, i could find some not implemented from the code, so i would be glad if we could discuss what are the intended abstract attributes to be done and their order of dependance :)

Cheers,
Omar Ahmed

On Tue, Mar 3, 2020 at 8:18 PM Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>> wrote:
Correct. Not implement yet

--
written from my phone
________________________________
From: Omar Ahmed <omarpiratee2010 at gmail.com<mailto:omarpiratee2010 at gmail.com>>
Sent: Tuesday, March 3, 2020 12:07:59 PM
To: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
Subject: Re: GSOC2020 LLVM project : Attributor framework

Ok, thanks for the clarification. :D
I have another small question :) , I can't understand what AAReachability Attribute does , I guess also it is not implemented yet right ? as I have found only functions without code

On Tue, Mar 3, 2020 at 7:36 PM Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>> wrote:
In this case it is mostly because the code is complex and uses functions that are not available in the header (without including more headers there).

---------------------------------------
Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>

________________________________________
From: Omar Ahmed <omarpiratee2010 at gmail.com<mailto:omarpiratee2010 at gmail.com>>
Sent: Tuesday, March 3, 2020 11:19
To: Doerfert, Johannes
Subject: Re: GSOC2020 LLVM project : Attributor framework

Nothing actually only though there is a reason in design for doing that , but I guess there is not :)
Thanks

Cheers,
Omar Ahmed

On Tue, Mar 3, 2020 at 7:13 PM Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>> wrote:
Hi Omar,

what is the difference you expect when functions are implemented in the .h vs .cpp file (or vice versa)?

Cheers,
  Johannes

________________________________________
From: Omar Ahmed <omarpiratee2010 at gmail.com<mailto:omarpiratee2010 at gmail.com><mailto:omarpiratee2010 at gmail.com<mailto:omarpiratee2010 at gmail.com>>>
Sent: Tuesday, March 3, 2020 10:35
To: Doerfert, Johannes
Subject: Re: GSOC2020 LLVM project : Attributor framework

Greetings Mr Johannes,

I wanted to ask a very small question when u have time :) , I have found while reading the code of the attributor that IRPosition::getAssociatedArgument() function is implemented in file Attributor.cpp and all other functions of IRposition class is in Attributor.h so is there a reason why this function is the only one like that , also shouldn't all this IRposition functions implementation be in Attributor.cpp file and not in .h file ?

Cheers,
Omar Ahmed

On Sat, Feb 15, 2020 at 6:43 PM Johannes Doerfert <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>>> wrote:
Hi Omar,

On 02/15, omar ahmed wrote:
> I have some questions that bothers me

> 1- I have written the code and a single test.c file that contains for loop
> and generated the test.ll file for it to test our function, now how could I
> test the function and run it on the test.ll file to see what it outputs ?
> or how could I test the attribute functions in general ?

One way is to run the Attributor as part of the regular pipeline, e.g.,
  clang -O2 -mllvm -attributor-disable=false test.c -emit-llvm -S -o test.ll
or
  opt -O2 -mllvm -attributor-disable=false test.ll -S -o test_opt.ll

Another way is to prepare the code and the run the Attributor as a
single pass explicitly, that is what all tests do. Check out the files in
llvm/test/Transforms/Attributor/ to see how this looks. In order to
prepare the test, at least to get the IR part right, you can run the
polly test create script (from the llvm-project with opt/clang in your
path):
  ./polly/test/create_ll.sh test.c
which results in test.ll that is "nice". To do this manually you would
run
  clang -O2 -emit-llvm -mllvm -disable-llvm-optzns -S -o test.ll test.c
and then
  opt -mem2reg test.ll -S -o test.ll

Btw. the functionality you are working on should affect existing tests.
You should run them, e.g.,
  ./bin/llvm-lit <PATH>/llvm-project/llvm/test/Transforms/Attributor/ -v
in your build folder with <PATH> replaced by wherever your llvm-project
lives.

> 2- I have written the code in the containsCycle function but now the
> containsCycle function not only tests if there is a loop but also if that
> loop will terminate so that seems like containsPossiblyEndlessLoop don't do
> anything in this case except it call containsCycle function so does this
> right ? I have thought of writing the task in containsPossiblyEndlessLoop
> function but that will make us loop on the blocks of the function again and
> we already loop on it in the containsCycle function so it didn't seem right
> to me , does I get something wrong in my understanding of this functions so
> does I understand the behaviour of two functions right ?

Write it in containsCycle for now and then we'll go from there. We can
later move it during the code review.

I hope this helps.

Cheers,
  Johannes

> cheers,
>  Omar
>
> On Thu, Feb 13, 2020 at 8:27 AM Johannes Doerfert <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>>> wrote:
>
> > Hi Omar,
> >
> > I'm glad you are interested in the project. I'm not sure what exactly
> > you want from me at this time. Do you have specific questions?
> >
> > If you need a small task to work on I can recommend some.
> >
> > One way is to work on a TODO. There is a potentially suitable one just
> > before the definition of `AAWillReturnImpl`. The idea is that we
> > currently give up on `willreturn` if a function has a cycle = loop. This
> > is bad. We should ask analysis, e.g., ScalarEvolution if a loop that we
> > encounter has a known upper bound on the number of iterations. How to
> > query ScalarEvolution from the Attributor you can see if you look for
> > `ScalarEvolution` in the Attributor.cpp. The caveat is that we need to
> > identify the loops and also make sure there is no irreducible control
> > flow. I think if the `containsCycle` function finds a cycle we should
> > ask LoopInfo if the block already visited is a loop header. If not, it
> > is irreducible control and we give up, if it is a header we get the
> > `Loop` object from LoopInfo and ask ScalarEvolution if it knows an upper
> > bound on the iteration number, If so, the loop is fine wrt.
> > `willreturn`.
> >
> > Does that make some sense? Please feel free to always ask questions. We
> > can also look into a different first task if you prefer.
> >
> > Cheers,
> >   Johannes
> >
> >
> >
> > On 02/10, omar ahmed wrote:
> > > Greetings
> > >
> > > Dear Mr. Johannes
> > > I am a last year computer Engineering student at Ainshams university , I
> > > would like to participate in GSOC2020 and I was interested in Improve
> > > inter-procedural analyses and optimizations  , I have a good knowledge in
> > > c++ as I am using it in my projects and in problem solving ( have
> > > participated in ACM ACPC Regional contest) for 2 years now .
> > > In the past 3 weeks I have done building LLVM and read the documentation
> > > and watched some of the videos in LLVM meetings and especially the ones
> > in
> > > the preparation section in the project description, so if you could guide
> > > me through the project in the upcoming weeks I would be glad or even give
> > > me a task related to the project .
> > >
> > > Yours,
> > > Omar Ahmed
> >
> > --
> >
> > Johannes Doerfert
> > Researcher
> >
> > Argonne National Laboratory
> > Lemont, IL 60439, USA
> >
> > jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>>
> >

--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov><mailto:jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>>