[llvm-dev] A couple ideas for possible GSoC projects

[Mehdi Amini via llvm-dev]

Hi Philip,


> On Mar 22, 2016, at 4:43 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> If there are any students looking for ideas, here a couple of projects you might consider.
> 
> p.s. Anyone know where in the repo the OpenProjects page is?  I'd expected it to be the docs/ folder of the LLVM repo, but it wasn't.

Is it what you're looking for: http://llvm.org/svn/llvm-project/www/trunk/OpenProjects.html ?

-- 
Mehdi

PS: great projects below!

> 
> Transactional Memory Optimization
> Intel recently introduced transactional memory support in hardware. This project would consist of implementing optimizations which are only legal inside a transactional region (e.g. removing release fences since all stores must appear atomically as seen by other threads.)  This project will involved a good amount of research into what the hardware guarantees and reasoning about what optimizations that allows.  This project is probably best for a student with experience reasoning about concurrency at the hardware level.
> 
> Thread Local Optimization
> A compare-and-swap instruction executed against a location which is provably thread local can be converted into a load, test, and store.  Many other instructions intended for cross thread interaction have cheaper variants which apply to thread local locations.  The key part of this project will be introducing an analysis (probably based on CaptureTracking) to prove memory locations are thread local.  This project is probably best for a student with experience reasoning about concurrency in software.
> 
> Capture Tracking Improvements
> Our current capture tracking analysis (see CaptureTracking.cpp) is relatively weak and expensive.  It could be improved in a number of ways:
> 1) Review cases where potentially captured is currently returned for possible false positives.  There are a couple of known ones which would make good introductory patches.
> 2) The results could be cached to amortize the cost.  This will require careful design to ensure the result is invalidated when appropriate.
> 3) A more precise analysis could be used to identify object sub-graphs which do not escape (despite links between them).
> This would be a good project for a student interested in compiler analysis with strong skills in designing appropriate data structures for the task at hand.
> 
> Dereferenceability Analysis
> Currently LLVM has a number of places in code which reason about the dereferenceability of memory.  This project would involve consolidating all of those into a common set of utilities, reviewing each use for possibly improvements in compile time and precision, and possibly introducing a caching layer (analysis pass) to allow the use of more expensive reasoning.
> 
> ValueTracking Analysis
> ValueTracking is a key analysis framework used by LLVM, but it is currently structured as a set of recursive queries with limited depth.  There is no caching of queries which can result in substantial losses in compile time.  Introducing a caching layer (probably in the form of an Analysis pass) would be a useful improvement.  However, there are significant complications around invalidation of the cached information (e.g. simplifyDemandedBits) which will require careful thought and design.  This project would probably be best for a student with some existing experience in the LLVM code base.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev