[llvm-dev] GSoC Project - Advanced Heuristics and ML

[Johannes Doerfert via llvm-dev]

On 3/18/20 7:05 PM, Emanuel Lima wrote:
 >
 >     Did you get a list of papers from EJ by now?
 >
 > No. You are the first answer I get :(

Apologies for that. I got the list yesterday and put them on the
OpenProjects page.


 >     Do you have LLVM+Clang+TestSuite set up so you can run the test 
suite?
 >
 > Not yet. I was focusing on studying specific things about autotuning.
 > But I should have set that up already. I am going to do that now.

That would be good. I will describe a small task below that I think
would go in the right direction and that is useful for us right now. But
you'll need the setup working.


 >     We should also look at a small problem to get you started with the
 >     upstreaming process. Do you have one already?
 >
 > No. I was looking for one that would be close to the project, but
 > could not find it.

Last year we wrote an inter-procedural framework for fixpoint iterations
called "Attributor". Right now we are missing all but the simplest
heuristics as we started to make it "applicable" first. As with
everything we want to do in this project we will need to generate data
on which we can act first. To this end, I would like you to add special
"debug output" into Attributor.cpp which we can use to learn more about
what is happening.

There are two videos on youtube you might want to check out but the
basic idea is that the Attributor has a list of AbstractAttributes on
which "update" is called until nothing changes anymore. Now one of the
things we would like to know is how often is update called on what kind
of AbstractAttributes, e.g., what is the subclass. To determine this in
a sensible way we need to collect the subclass information every time
update is called. We could use -debug-only=attributor for this but it
would also print too much other stuff. I suggest we add DEBUG_TYPE
macros in the update method that print the subclass type, e.g., as
defined by the address of the ID member. We could also print the string
representation but that would be more expensive.

To be honest, we should probably determine if there is a better way to
gather information like this as it will be necessary more often. If not,
we should write infrastructure to help. Though, let's start with one use
case and go from there.

Please let me know if this makes sense and always feel free to ask
questions!

Cheers,
   Johannes

 > Em qua., 18 de mar. de 2020 às 20:11, Johannes Doerfert 
<johannesdoerfert at gmail.com> escreveu:
 >
 >     Hi Emanuel,
 >
 >     Apologies for the delay in my responses.
 >
 >     Did you get a list of papers from EJ by now?
 >     Do you have LLVM+Clang+TestSuite set up so you can run the test 
suite?
 >
 >     We should also look at a small problem to get you started with the
 >     upstreaming process. Do you have one already?
 >
 >     Thanks,
 >       Johannes
 >
 >     On 03/16, Emanuel Lima wrote:
 >     > Hello everybody. Last monday I sent an email to the LLVM dev 
mailing list
 >     > saying that I was looking forward to working on these GSoC 
projects:
 >     > *Advanced Heuristics for Ordering Compiler Optimization Passes*
 >     > and
 >     > *Machine learning and compiler optimizations: using 
inter-procedural
 >     > analysis to select optimization*
 >     > I currently do an undergraduate research on compiler autotuning 
of Rust
 >     > code, more specifically, autotuning of optimization passes of 
the LLVM IR.
 >     > I would very much like to work on these projects, but I don't 
know where to
 >     > start. What should be my next steps?
 >     > GSoC applications will open soon, so I am a little nervous...
 >     >
 >     > --
 >     > Emanuel Lima
 >
 >     --
 >
 >     Johannes Doerfert
 >     Researcher
 >
 >     Argonne National Laboratory
 >     Lemont, IL 60439, USA
 >
 >     jdoerfert at anl.gov
 >
 >
 >
 > --
 > Emanuel Lima