> 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
>
> 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
>
> > 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