This is an archive of the discontinued LLVM Phabricator instance.

Add GSOC landing page with instructions for GSOC students.
Needs ReviewPublic

Authored by tonic on Mar 14 2022, 9:44 AM.

Download Raw Diff

Details

Reviewers

nlopes
asl
jdoerfert
sstefan1
baziotis

Diff Detail

Repository

rW llvm-www

Build Status

Buildable 154143
Build 228861: arc lint + arc unit

Event Timeline

tonic created this revision.Mar 14 2022, 9:44 AM

Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 9:44 AM

tonic requested review of this revision.Mar 14 2022, 9:44 AM

Harbormaster completed remote builds in B154123: Diff 415125.Mar 14 2022, 9:44 AM

tonic added reviewers: nlopes, asl.Mar 14 2022, 9:50 AM

Adding changes to the Open projects page to remove old GSOC data and link to the landing page. Add a link to a GSOC template

Herald added a reviewer: jdoerfert. · View Herald TranscriptMar 14 2022, 10:50 AM

Herald added a reviewer: jdoerfert. · View Herald Transcript

Herald added a reviewer: sstefan1. · View Herald Transcript

Herald added a reviewer: baziotis. · View Herald Transcript

Herald added a subscriber: sstefan1. · View Herald Transcript

Harbormaster completed remote builds in B154143: Diff 415159.Mar 14 2022, 10:50 AM

asl added inline comments.Mar 14 2022, 10:52 AM

OpenProjects.html
1448	I think it does make sense to keep link to old projects as this might be a good guidance for the students what to expect

tonic added inline comments.Mar 14 2022, 11:02 AM

OpenProjects.html
1448	Can I add links to the GSOC participation from previous years to the new GSOC landing page? At the bottom after useful links I can link to each official GSOC page that lists the projects that were successful.

Another idea, would it be ok to link directly to either Discord or Discourse usernames for the mentors? That way it is easer to find or tag people.

I don't know how to frame this nicely, but I think it's important to set the expectations right: what kind of support can students expect from mentors? Mentors aren't their babysitter nor have the responsibility to fix the bugs for them. Nor fix compilation errors. I would like to have this written down given some bad experiences in the past.
Mentor's time is expensive and scarce, so use it wisely. The mentor is there to guide only, not to teach how to code.

Another thing, not sure we want to make the point here. Most of LLVM's contributors work in tech companies. So GSoC can be seen as an interview. Students should grab the opportunity, learn, work hard, and impress folks. They are likely to get an internship at the end if they do that.

I would also like to ask all students to at least write a blog post at the end. The best should give a talk at the following dev conference. Another incentive for the students to work hard.

GSOC.html
33	I like this suggestion. I started my open-source life as a documentation writer, even if my English wasn't particularly good back then. A suggestion is to link to the github's "easy bugs" issues. Fixing one of those probably increases the chances of being accepted by 10x. There aren't that many bugs tagged as easy. In general most InstSimplify/InstCombine are the easiest around (not all though).

@nlopes I think we need to better frame the requirement then, ask for CVs (this is always done though) and maybe even organize some kind of interviews? Strongly favouring ones with prior contributions is a good thing IMO

In D121614#3394190, @asl wrote:

@nlopes I think we need to better frame the requirement then, ask for CVs (this is always done though) and maybe even organize some kind of interviews? Strongly favouring ones with prior contributions is a good thing IMO

I agree, I interview students these days.

We should incentivize folks with prior contributions, totally (though that's extremely rare). At least a bug fix so we know they can code. Usually fixing some InstCombine/InstSImplify bug is within reach of newbies.

In D121614#3394221, @nlopes wrote:

In D121614#3394190, @asl wrote:

@nlopes I think we need to better frame the requirement then, ask for CVs (this is always done though) and maybe even organize some kind of interviews? Strongly favouring ones with prior contributions is a good thing IMO

I agree, I interview students these days.

We should incentivize folks with prior contributions, totally (though that's extremely rare). At least a bug fix so we know they can code. Usually fixing some InstCombine/InstSImplify bug is within reach of newbies.

I think this is really up to the mentors. Some mentors may be ok with having someone more junior and some would prefer someone more advanced. Both are ok as long as the expectations are clear in the project description.

Revision Contents

Path

Size

GSOC.html

2 lines

OpenProjects.html

1789 lines

Diff 415159

GSOC.html

	Show All 24 Lines
	</ul>			</ul>
	</p>			</p>

	<div class="www_sectiontitle" id="contribute">Make a small contribution</div>			<div class="www_sectiontitle" id="contribute">Make a small contribution</div>

	<p>			<p>
	One important step is to get familiar with the LLVM Project development workflow and tools used. Make one small contribution to the project to show that you can checkout the source, build the application, make changes, and submit a patch using our code review tool called Phabricator. Please see our <a href="https://llvm.org/docs/Contributing.html">Contributor's Guide</a> with instructions on how to contribute to the LLVM Project.			One important step is to get familiar with the LLVM Project development workflow and tools used. Make one small contribution to the project to show that you can checkout the source, build the application, make changes, and submit a patch using our code review tool called Phabricator. Please see our <a href="https://llvm.org/docs/Contributing.html">Contributor's Guide</a> with instructions on how to contribute to the LLVM Project.
	</p>			</p>
	<p>If you are having trouble coming up with a small contribution, we recommend updating documentation as it involves many of the same steps as code contributions.			<p>If you are having trouble coming up with a small contribution, we recommend updating documentation as it involves many of the same steps as code contributions.
				nlopesUnsubmitted Not Done Reply Inline Actions I like this suggestion. I started my open-source life as a documentation writer, even if my English wasn't particularly good back then. A suggestion is to link to the github's "easy bugs" issues. Fixing one of those probably increases the chances of being accepted by 10x. There aren't that many bugs tagged as easy. In general most InstSimplify/InstCombine are the easiest around (not all though). nlopes: I like this suggestion. I started my open-source life as a documentation writer, even if my…
	</p>			</p>

	<div class="www_sectiontitle" id="select">Select a GSOC project</div>			<div class="www_sectiontitle" id="select">Select a GSOC project</div>

	<p>			<p>
	We have a list of Open Projects that you can choose from. Each project listing has a description of the project, difficulty rating, length, and how to contact the mentors. If you have any questions about the project, you should ask the mentor(s).			We have a list of Open Projects that you can choose from. Each project listing has a description of the project, difficulty rating, length, and how to contact the mentors. If you have any questions about the project, you should ask the mentor(s).
	</p>			</p>

	Show All 11 Lines
	</ul>			</ul>
	</li>			</li>
	<li>Information about your proposed project. This should be fairly detailed and include a timeline.</li>			<li>Information about your proposed project. This should be fairly detailed and include a timeline.</li>
	<li>Information about other commitments that might affect your ability to work during the GSOC period (exams, classes, holidays, other jobs, weddings, etc.) . Also, if the project allows both medium- and large-size participation, indicate the intended size of the project and the timeframe of your participation.			<li>Information about other commitments that might affect your ability to work during the GSOC period (exams, classes, holidays, other jobs, weddings, etc.) . Also, if the project allows both medium- and large-size participation, indicate the intended size of the project and the timeframe of your participation.
	</li>			</li>
	</ul>			</ul>
	</p>			</p>

	<p>Feel free to copy and use our Template GSOC Proposal</p>			<p>Feel free to copy and use our <a href="https://docs.google.com/document/d/1g48HOuLoA8EFOUBwDGUiZ31l7hUIb1Crff6kEUteLrQ/edit?usp=sharing">Template GSOC Proposal</a></p>

	<div class="www_sectiontitle" id="engage">Engage with your mentor about your project</div>			<div class="www_sectiontitle" id="engage">Engage with your mentor about your project</div>

	<p>Your proposal should be discussed with your mentor prior to submitting it to GSOC. You can find the contact's for each mentor on the Open Projects List.			<p>Your proposal should be discussed with your mentor prior to submitting it to GSOC. You can find the contact's for each mentor on the Open Projects List.
	</p>			</p>

	<div class="www_sectiontitle" id="submit">Submit your application</div>			<div class="www_sectiontitle" id="submit">Submit your application</div>

	Show All 24 Lines

OpenProjects.html

Show All 28 Lines	<ul>
provide information for the type as written in template		provide information for the type as written in template
instantiations</a>		instantiations</a>
</li>		</li>
<li><a href="#clang-sa-structured-bindings">Implement support for		<li><a href="#clang-sa-structured-bindings">Implement support for
C++17 structured bindings in the Clang Static Analyzer</a>		C++17 structured bindings in the Clang Static Analyzer</a>
</li>		</li>
</ul>		</ul>
</li>		</li>

</ul>
</li>
<li>
<a href="#gsoc21">Google Summer of Code 2021</a>
<ul>
<li>
<b>LLVM Core</b>
<ul>
<li><a href="#llvm_distributing_lit">Distributed lit testing</a></li>
<li><a href="#llvm_loop_heuristics">Learning Loop Transformation Heuristics</a></li>
<li><a href="#llvm_ir_fuzzing">Fuzzing LLVM-IR Passes</a></li>
<li><a href="#llvm_ir_assume"><tt>llvm.assume</tt> the missing pieces</a></li>
<li><a href="#llvm_shared_jitlink">Implement a shared-memory based JITLinkMemoryManager for out-of-process JITting</a></li>
<li><a href="#llvm_build_jit_tutorial">Modernize the LLVM "Building A JIT" tutorial series</a></li>
<li><a href="#llvm_jit_new_format">Write JITLink support for a new format/architecture</a></li>
<li><a href="#llvm_ir_issues">Fix fundamental issues in LLVM's IR</a></li>
<li><a href="#llvm_utilize_loopnest">Utilize LoopNest Pass</a></li>
</ul>
</li>
<li><a href="http://clang.llvm.org/"><b>Clang</b></a>
<ul>
<li><a href="#clang-template-instantiation-sugar">Extend clang AST to
provide information for the type as written in template
instantiations</a>
</li>
</ul>
</li>
<li>
<b>OpenMP</b>
<ul>
<li><a href="#openmp_gpu_jit">JIT-ing OpenMP GPU kernels transparently</a></li>
</ul>
</li>
<li>
<b>OpenACC</b>
<ul>
<li><a href="#openacc_rt_diagnostics">OpenACC Diagnostics from the OpenMP Runtime</a></li>
</ul>
</li>
<li>
<b><a href="https://polly.llvm.org">Polly</a></b>
<ul>
<li><a href="#polly_isl_bindings">Use official isl C++ bindings</a></li>
</ul>
</li>
<li>
<b><a href="https://enzyme.mit.edu">Enzyme</a></b>
<ul>
<li><a href="#enzyme_blas">Integrate custom derivatives of BLAS, Eigen, and similar routines into Enzyme</a></li>
<li><a href="#enzyme_swift">Integrate Enzyme into Swift to provide high-performance differentiation in Swift</a></li>
<li><a href="#enzyme_fixed">Differentiation of Fixed-Point Arithmetic</a></li>
<li><a href="#enzyme_rust">Integrate Enzyme into Rust to provide high-performance differentiation in Rust</a></li>
</ul>
</li>
<li>
<b>Clang Static Analyzer</b>
<ul>
<li><a href="#static_analyzer_profling">Clang Static Analyzer performance profiling</a></li>
<li><a href="#static_analyzer_constraint_solver">Clang Static Analyzer constraint solver improvements</a></li>
</ul>
</li>
<li>
<b>LLDB</b>
<ul>
<li><a href="#lldb_diagnostics">A structured approach to diagnostics in LLDB</a></li>
</ul>
</li>
</ul>
</li>
<li>
<a href="#gsoc20">Google Summer of Code 2020</a>
<ul>
<li>
<b>LLVM Core</b>
<ul>
<li><a href="#llvm_optimized_debugging">Improve debugging of optimized code</a></li>
<li><a href="#llvm_ipo">Improve inter-procedural analyses and optimizations</a></li>
<li><a href="#llvm_par">Improve parallelism-aware analyses and optimizations</a></li>
<li><a href="#llvm_dbg_invariant">Make LLVM passes debug info invariant</a></li>
<li><a href="#llvm_mergesim">Improve MergeFunctions to incorporate MergeSimilarFunction patches and ThinLTO Support</a></li>
<li><a href="#llvm_dwarf_yaml2obj">Add DWARF support to yaml2obj</a></li>
<li><a href="#llvm_hotcold">Improve hot cold splitting to aggressively outline small blocks</a></li>
<li><a href="#llvm_pass_order">Advanced Heuristics for Ordering Compiler Optimization Passes</a></li>
<li><a href="#llvm_ml_scc">Machine learning and compiler optimizations: using inter-procedural analysis to select optimizations</a></li>
<li><a href="#llvm_postdominators">Add PostDominatorTree in LoopStandardAnalysisResults</a></li>
<li><a href="#llvm_loopnest">Create loop nest pass</a></li>
<li><a href="#llvm_instdump">Instruction properties dumper and checker</a></li>
<li><a href="#llvm_movecode">Unify ways to move code or check if code is safe to be moved</a></li>
</ul>
<li><a href="http://clang.llvm.org/"><b>Clang</b></a>
<ul>
<li><a href="#clang-template-instantiation-sugar">Extend clang AST to
provide information for the type as written in template
instantiations</a>
</li>
<li><a href="#clang-sa-cplusplus-checkers">Find null smart pointer dereferences
with the Static Analyzer</a>
</li>
</ul>
</li>
<li><a href="http://lldb.llvm.org/"><b>LLDB</b></a></li>
<ul>
<li><a href="#lldb-autosuggestions">Support autosuggestions in LLDB's command line</a></li>
<li><a href="#lldb-more-completions">Implement the missing tab completions for LLDB's command line</a></li>
<li><a href="#lldb-reimplement-lldb-cmdline">Reimplement LLDB's command-line commands using the public SB API.</a></li>
<li><a href="#lldb-batch-testing">Add support for batch-testing to the LLDB testsuite.</a></li>
</ul>
<li>
<b>MLIR</b>
<ul>
<li>See the <a href="https://mlir.llvm.org/getting_started/openprojects/">MLIR open project list</a></li>
</ul>
</li>
</ul>

</li>
<li><a href="#gsoc19">Google Summer of Code 2019</a>
<ul>
<li>
<b>LLVM Core</b>
<ul>
<li><a href="#debuginfo_codegen_mismatch">Debug Info should have no
effect on codegen</a></li>
<li><a href="#llvm_function_attributes">Improve (function) attribute
inference</a></li>
<li><a href="#improve_binary_utilities">Improve LLVM binary utilities
</a></li>
</ul>		</ul>
</li>		</li>
<li><a href="http://clang.llvm.org/"><b>Clang</b></a>
<ul>
<li><a href="#clang-astimporter-fuzzer">Implement an ASTImporter
fuzzer</a>
</li>
<li><a href="#improve-autocompletion">Improve shell autocompletion
for Clang</a>
</li>
<li><a href="#analyze-llvm">Apply the Clang Static Analyzer to LLVM-based
Projects</a>
</li>
<li><a href="#header-generation">Generate annotated sources based on
LLVM-IR analyses</a>
</li>
<li><a href="#header-clang-diagnostic">Improve Clang diagnostics</a>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#gsoc18">Google Summer of Code 2018</a></li>
<li><a href="#gsoc17">Google Summer of Code 2017</a></li>
</ul></li>		</ul></li>
<li><a href="#what">What is this?</a></li>		<li><a href="#what">What is this?</a></li>
<li><a href="#subprojects">LLVM Subprojects: Clang and more</a></li>		<li><a href="#subprojects">LLVM Subprojects: Clang and more</a></li>
<li><a href="#improving">Improving the current system</a>		<li><a href="#improving">Improving the current system</a>
<ol>		<ol>
<li><a href="#target-desc">Factor out target descriptions</a></li>		<li><a href="#target-desc">Factor out target descriptions</a></li>
<li><a href="#code-cleanups">Implementing Code Cleanup bugs</a></li>		<li><a href="#code-cleanups">Implementing Code Cleanup bugs</a></li>
<li><a href="#programs">Compile programs with the LLVM Compiler</a></li>		<li><a href="#programs">Compile programs with the LLVM Compiler</a></li>
▲ Show 20 Lines • Show All 41 Lines • ▼ Show 20 Lines	<p>
your starting point to finding interesting and important projects for LLVM,		your starting point to finding interesting and important projects for LLVM,
Clang, and other related sub-projects. This list of projects is not only		Clang, and other related sub-projects. This list of projects is not only
developed for Google Summer of Code, but open projects that really need		developed for Google Summer of Code, but open projects that really need
developers to work on and are very beneficial for the LLVM community.		developers to work on and are very beneficial for the LLVM community.
</p>		</p>

<p>We encourage you to look through this list and see which projects excite		<p>We encourage you to look through this list and see which projects excite
you and match well with your skill set. We also invite proposals not on this		you and match well with your skill set. We also invite proposals not on this
list. More information and discussion about GSoC can be found in		list. For full details on how to apply and required steps, please see our <a href="https://llvm.org/GSOC.html">Google Summer of Code page.</a>
<a href="https://discourse.llvm.org/c/community/gsoc" target="_blank">
discourse
</a>. If you have questions about a particular project please find the
relevant entry in discourse, check previous discussion and ask. If there is
no such entry or you would like to propose an idea please create a new
entry. Feedback from the community is a requirement for your proposal to be
considered and hopefully accepted.
</p>

<p>The LLVM project has participated in Google Summer of Code for several years
and has had some very successful projects. We hope that this year is no
different and look forward to hearing your proposals. For information on how
to submit a proposal, please visit the Google Summer of Code main
<a href="https://summerofcode.withgoogle.com/">website.</a>
</p>		</p>
</div>		</div>

<!-- *********************************************************************** -->		<!-- *********************************************************************** -->
<div class="www_subsection">		<div class="www_subsection">
<a>LLVM</a>		<a>LLVM</a>
</div>		</div>
<!-- *********************************************************************** -->		<!-- *********************************************************************** -->
▲ Show 20 Lines • Show All 551 Lines • ▼ Show 20 Lines	<div class="www_text">
<p><b>Discourse</b>		<p><b>Discourse</b>
<a href="https://discourse.llvm.org/t/implement-support-for-c-17-structured-bindings-in-the-clang-static-analyzer/60588">		<a href="https://discourse.llvm.org/t/implement-support-for-c-17-structured-bindings-in-the-clang-static-analyzer/60588">
URL</a>		URL</a>
</p>		</p>
</div>		</div>

<!-- *********************************************************************** -->		<!-- *********************************************************************** -->
<div class="www_sectiontitle">		<div class="www_sectiontitle">
<a name="gsoc21">Google Summer of Code 2021</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>
Welcome prospective Google Summer of Code 2021 Students! This document is your
starting point to finding interesting and important projects for LLVM, Clang,
and other related sub-projects. This list of projects is not only developed for
Google Summer of Code, but open projects that really need developers to work on
and are very beneficial for the LLVM community. </p>

<p>We encourage you to look through this list and see which projects excite you
and match well with your skill set. We also invite proposals not on this
list. You must propose your idea to the LLVM community through our
developers' mailing list (llvm-dev@lists.llvm.org or specific subproject mailing
list). Feedback from the community is a requirement for your proposal to be
considered and hopefully accepted.
</p>

<p>The LLVM project has participated in Google Summer of Code for several years
and has had some very successful projects. We hope that this year is no
different and look forward to hearing your proposals. For information on how to
submit a proposal, please visit the Google Summer of Code
main <a href="https://developers.google.com/open-source/gsoc/">website.</a></p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>LLVM</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_distributing_lit">Distributed lit testing</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
The LLVM lit test suites consist of thousands of small independent tests.
Due to the number of tests, it can take a long time to run the full suite,
even on a high-spec computer. Builds are already distributable across
multiple computers available on the same network, using software such as
distcc or icecream, so running tests on a single machine becomes a potential
bottleneck. One way to speed up running of the tests could be to distribute
test execution across many computers too. Lit provides a test sharding
mechanism, which allows multiple computers to run parts of the same
testsuite in tandem, but this currently assumes access to a single common
filesystem, which may not be possible in all cases and a knowledge of which
machines the suite can currently be run on.

This project’s goal is to update the existing lit harness (or write a
wrapper around it) to allow distribution of the tests in this way, with the
idea that developers can write their own interface between the harness and
the distribution system of their choice. This harness may need to be able to
identify test dependencies such as input files and executables, send the
tests to the distribution system (possibly in batches), and receive, collate
and report the results to the user, in a similar manner to how lit already
does.
</p>

<p><b>Expected results:</b> An easy to use harness as described above. Some
evidence that given a distributed system, a user can expect to see test
suite execution to speed up if they are using that harness.</p>

<p><b>Confirmed mentor:</b> James Henderson</p>
<p><b>Desirable skills:</b> Good knowledge of Python. Familiarity with LLVM
lit testing. Some knowledge of distribution systems would also be
beneficial.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_loop_heuristics">Learning Loop Transformation Heuristics</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on
IRC) and Mircea Trofin if it sounds interesting.

We successfully introduced an ML framework for inliner decisions, now we want
to expand the scope. In this project we will look at loop transformation
heuristics, such as the unroll factor. As a motivational example we can look
at a small trip count <a href="https://godbolt.org/z/Eeqcvs">dgemm</a> which
we optimize pretty poorly. With the nounroll pragmas we do a better job but
still not close to gcc.

The project is open-ended and we could look at various passes/heuristics
concurrently.
</p>

<p><b>Preparation resources:</b> The ML inliner framework in the LLVM code
base as well as the <a href="https://arxiv.org/abs/2101.04808">paper</a>. LLVM
transform passes (that are based on heuristics), e.g., loop unroll.</p>

<p><b>Expected results:</b> Measurable better performance with a learned
predictor, potentially a set of "classical" heuristics derived from the ML
model.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert, Mircea Trofin</p>
<p><b>Desirable skills:</b> Intermediate knowledge of ML, C++, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_ir_fuzzing">Fuzzing LLVM-IR Passes</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on
IRC) if it sounds interesting.

Fuzzing often reveals a myriad of bugs. CSmith (and others) showed how to do
this with C-like languages and we have used <a
href="https://www.youtube.com/watch?v=UBbQ_s6hNgg">LLVM-IR fuzzing</a> in
the past successfully. In this project we will apply fuzzing to new passes
that are in development, e.g., the Attributor pass. We want to find and fix
crashes but also other bugs, including compile time performance problems.
</p>

<p><b>Preparation resources:</b> The <a
href="https://llvm.org/docs/FuzzingLLVM.html#llvm-opt-fuzzer">LLVM fuzzer
infrastructure</a>. LLVM passes that we might want to fuzz, e.g. the
Attributor pass. Prior IR-Fuzzing work
(https://www.youtube.com/watch?v=UBbQ_s6hNgg)</p>


<p><b>Expected results:</b> Crashes, maybe also a way to catch non-crash
bugs, including performance problems.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert</p>
<p><b>Desirable skills:</b> Intermediate knowledge C++, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_ir_assume"><tt>llvm.assume</tt> the missing pieces</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on
IRC) if it sounds interesting.

<tt>llvm.assume</tt> is a powerful mechanism to retain knowledge. Since it
inception it was improved already multiple times but there are major
extensions still outstanding which we want to tackled in this project.
An incomplete list of topics includes:
<ul>
<li> range-based assumptions, design idea 3) in the <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html">RFC</a>. </li>
<li> outline arbitrary assumption/assertion code, design idea 2) in the <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html">RFC</a>. </li>
<li> side-effect free assumptions, see <a href="https://reviews.llvm.org/D89054">this review</a>. </li>
<li> more knowledge retention usages </li>
<li> less interference with optimizations </li>
</ul>

</p>

<p><b>Preparation resources:</b> The llvm.assumption usage, the assumption
cache, the "enable-knowledge-retention" option, the <a
href="https://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html">RFC</a>
and <a href="https://reviews.llvm.org/D89054">this review</a>.
</p>


<p><b>Expected results:</b> New llvm.assume use cases, improved performance through knowledge retention, optimization based on assertions.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert</p>
<p><b>Desirable skills:</b> Intermediate knowledge C++, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_ir_issues">Fix fundamental issues in LLVM's IR</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
LLVM's IR has fundamental, long-standing issues. Many are related with
undefined behaviors. Others are simply a fallout from underspecification
and different interpretations by diffferent people.
<a href="https://github.com/AliveToolkit/alive2">Alive2</a> is a tool that
detects bugs in LLVM's optimizations automatically. Using Alive2, we track
bugs exposed by the unit tests on a
<a href="https://web.ist.utl.pt/nuno.lopes/alive2/">dashboard</a>.
</p>

<p><b>Expected results:</b>
1) Report and fix bugs detected by Alive2.
2) Pick one fundamental IR issue and
make progress towards fixing it, including proposing fixes for the
<a href="https://llvm.org/docs/LangRef.html">semantics</a>, testing
fixes to the semantics by running Alive2 over the LLVM unit tests and
medium-sized programs, test performance of semantic fixes and fix
performance regressions.
</p>
<p><b>Confirmed Mentor:</b> Nuno Lopes, Juneyoung Lee</p>
<p><b>Desirable skills:</b> Intermediate C++; willingness to learn about LLVM
IR semantics; experience reading papers (preferred).
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_utilize_loopnest">Utilize LoopNest Pass</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
The idea of LoopNest pass is recently added, and there are no existing
passes utilizing it. Before having LoopNest pass, if you want to write a
pass that works on a loop nest, you have to pick from either a function
pass or a loop pass. If you chose to write it as a function pass, then you
lose the ability to add loops dynamically back to the pipeline. If you
decide to write it as a loop pass, then you are wasting compile time to
traverse to your pass and return right away when the given loop is not the
outermost loop. In this project, we want to utilize the recently introduced
LoopNest pass for passes intended for loop nest and have the same ability
as the LoopPass to dynamically add loops to the pipeline. In addition,
improve the current implementation of LoopNestPass when necessary.
</p>
<p><b>Expected results (possibilities):</b>
Utilize LoopNest Pass for some existing transformations/analyses.
</p>
<p><b>Confirmed Mentors:</b>
Whitney Tsang, Ettore Tiotto
</p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++, self-motivation.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="openmp_gpu_jit">JIT-ing OpenMP GPU kernels transparently</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on
IRC) if it sounds interesting.

OpenMP GPU kernels are usually lowered to native binaries, e.g., cubin, and
embedded into the host object. At runtime, OpenMP "plugins" will connect with
the device driver, e.g., CUDA, to load and run such embedded binary images.
In this project we want to develop a new plugin that takes LLVM-IR code, optimizes
the IR with kernel parameters known only at runtime, and then generates the GPU
binary for consumption by other plugins. Similar to the <a
href=https://openmp.llvm.org/docs/design/Runtimes.html#remote-offloading-plugin>remote
offload plugin</a> we can do this transparently to the user. In addition to the JIT
infrastructure setup in the plugin we will need to embed the IR into the host object.

</p>

<p><b>Preparation resources:</b>OpenMP target offloading infrastructure, LLVM JIT infrastructure</a>.
</p>


<p><b>Expected results:</b> A JIT-capable offload plugin which can achieve superior performance when kernel specialization is enabling optimizations.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert</p>
<p><b>Desirable skills:</b> Intermediate knowledge C++, JIT compilation, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>OpenACC</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="openacc_rt_diagnostics">OpenACC Diagnostics from the OpenMP Runtime</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Clacc and Flacc are projects to introduce OpenACC support to Clang and
Flang. For that purpose, OpenACC runtime support is being developed on top
of LLVM's OpenMP runtime. However, diagnostics emitted by LLVM's OpenMP
runtime are expressed in terms of OpenMP concepts, and so those diagnostics
are not always meaningful to OpenACC users. This project should address
this issue in two steps:
<ol>
<li>
Develop a mechanism that selects OpenACC versions of diagnostics that
are emitted as a result of OpenACC-related calls into the runtime. This
mechanism should be general enough that it could be used for programming
languages besides OpenMP and OpenACC. One possible approach is to
extend internationalization mechanisms already present in some
components of the OpenMP runtime.
</li>
<li>
Provide OpenACC translations for existing OpenMP diagnostics. This step
requires an understanding of the relationship between OpenACC and OpenMP
as implemented in Clacc and Flacc.
</li>
</ol>
Many components of OpenACC support that will depend upon this project have
not yet been upstreamed and are under development. A high-level
understanding of those efforts is helpful for this project and can be
provided by the mentors. Nevertheless, this project can be completed in
upstream LLVM's OpenMP runtime now independently of those efforts.
</p>

<p>
<b>Expected results:</b> A version of upstream LLVM's OpenMP runtime that
can emit OpenACC diagnostics as needed.
</p>

<p><b>Confirmed Mentors:</b> Valentin Clement, Joel E. Denny</p>

<p>
<b>Desirable skills:</b> Intermediate C++; Experience with OpenACC or
OpenMP
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>Polly</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="polly_isl_bindings">Use official isl C++ bindings</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Polly use algorithms from the
<a href="http://isl.gforge.inria.fr/">Integer Set Library (isl)</a>, which is a
library written in C. It uses reference-counting for memory management.
Getting reference counting correct is much easier in C++ using RAII,
therefore we created a C++ binding for isl:
<a href="https://github.com/llvm/llvm-project/blob/main/polly/lib/External/isl/include/isl/isl-noexceptions.h">isl-noexceptions.h</a>.
Since then, isl also gained two official C++ bindings,
<a href="https://github.com/llvm/llvm-project/blob/main/polly/lib/External/isl/include/isl/cpp.h">cpp.h</a>
and
<a href="https://github.com/llvm/llvm-project/blob/main/polly/lib/External/isl/include/isl/cpp-checked.h">cpp-checked.h</a>.

We would like to replace the Polly-maintained C++ bindings with the upstream
bindings. Unfortunately, this is not an in-place replacement. Differences
include how errors are checked, method names, which functions are
considered as operator/constructor overloads and the set of exported functions.
This will require changing Polly's uses of the C++ bindings and submitting
patches to isl to export additional functionality needed by Polly.
</p>

<p><b>Expected results:</b>
Reduce the differences between the Polly-maintained isl-noexceptions.h
bindings and one of the two C++ bindings that isl supports. Due to
isl-noexceptions.h exporting more functions and classes than the upstream
bindings do, a complete replacement will probably be out of reach, but
even reducing the differences will reduce the maintenance cost of Polly's
isl-noexceptions.h.
</p>

<p><b>Confirmed mentor:</b> Michael Kruse</p>
<p><b>Desirable skills:</b>
Deep knowledge of C++, in particular RAII and move-semantics. Interest in API design. Ideally, you already wrote some library's header file.
Experience with the isl library would be nice, but can also be learned in the project.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>Enzyme</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="enzyme_blas">Integrate custom derivatives of BLAS, Eigen, and similar routines into Enzyme</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<a href="https://enzyme.mit.edu/">Enzyme</a> performs automatic differentiation
(in the calculus sense) of LLVM programs. This enables users to use Enzyme to
perform various algorithms such as back-propagation in ML
or scientific simulation on existing code for any language that lowers to LLVM.

Enzyme does so by applying the chain rule to every instruction in every
function called by the original function to be differentiated. While functional,
this is not necessarily optimal for high-level matrix operations which may
have algebraic properties for faster derivative computation.

Enzyme also has a mechanism for specifying a custom gradient for a given function.
If a custom derivative is available, Enzyme will use that rather than fallback
to implementing its own.

Many programs use BLAS libraries to efficiently compute matrix and tensor
operations. This project would enable high-performance automatic differentiation
of BLAS and similar libraries (such as Eigen) by specifying custom derivative
rules for their operations.
</p>

<p><b>Expected results:</b>
Efficient differentiation of BLAS and Eigen codes by writing custom
derivative rules for matrix and tensor operations.
</p>

<p><b>Confirmed mentor:</b> <a href="mailto:wmoses@mit.edu">William Moses</a>, Johannes Doerfert</p>
<p><b>Desirable skills:</b>
Good knowledge of C++, calculus, and linear algebra. Experience with BLAS, Eigen,
or Enzyme would be nice, but can also be learned in the project.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="enzyme_swift">Integrate Enzyme into Swift to provide high-performance differentiation in Swift</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<a href="https://enzyme.mit.edu/">Enzyme</a> performs automatic differentiation
(in the calculus sense) of LLVM programs. This enables users to use Enzyme to
perform various algorithms such as back-propagation in ML
or scientific simulation on existing code for any language that lowers to LLVM.

While this functions for any frontend that emits LLVM IR, it may be desirable
to have closer integration between Enzyme and the frontend for the sake of
passing additional information and creating a better user experience.

Swift provides automatic differentiation through the use of specifying custom
derivative rules in the front-end. Enzyme could be integrated directly with
Swift, differentiating the eventual LLVM, but it would lose out on all this
additional information about custom derivatives. Moreover, calling into
Enzyme naiively would be without Type checking, fine AD-specific debug information,
or various other nice tools that Swift provides users of AD.

This project would seek to integrate Enzyme and the Swift front end to provide
both a nice user-experience for swift programmers who want to use Enzyme
to enable high-performance automatic differentiation, and also to allow Enzyme
to take advantage of derivative-specific metadata already available in swift.
</p>

<p><b>Expected results:</b>
Creation of a custom type-checked linguistic construct in Swift for calling Enzyme.
Mechanisms for passing Swift's differentiation-specific metadata for use by Enzyme.
</p>

<p><b>Confirmed mentor:</b> <a href="mailto:wmoses@mit.edu">William Moses</a>, Vassil Vassilev</p>
<p><b>Desirable skills:</b>
Good knowledge of C++ and Swift. Experience with Enzyme or automatic differentiation
would be nice, but can also be learned in the project.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="enzyme_fixed">Differentiation of Fixed-Point Arithmetic</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<a href="https://enzyme.mit.edu/">Enzyme</a> performs automatic differentiation
(in the calculus sense) of LLVM programs. This enables users to use Enzyme to
perform various algorithms such as back-propagation in ML
or scientific simulation on existing code for any language that lowers to LLVM.

In a variety of fields, it is desirable to compute on fixed-point values
(e.g. integers) rather than floating point values. This avoid certain truncation
errors that may be critical to a given application. Moreover, particular pieces
of hardware may simply be more efficient on fixed point rather than floating
point values.

This project would seek to extend Enzyme to support differentiation of not only
floating point base values, but also fixed point base values..
</p>

<p><b>Expected results:</b>
Implementation of adjoints for LLVM fixed point intrinsics, requisite type analysis
rules, and integration into a front-end for an end-to-end test.
</p>

<p><b>Confirmed mentor:</b> <a href="mailto:wmoses@mit.edu">William Moses</a></p>
<p><b>Desirable skills:</b>
Good knowledge of C++, caclulus, and LLVM internals. Experience with Enzyme or
automatic differentiation would be nice, but can also be learned in the project.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="enzyme_rust">Integrate Enzyme into Rust to provide high-performance differentiation in Rust</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<a href="https://enzyme.mit.edu/">Enzyme</a> performs automatic differentiation
(in the calculus sense) of LLVM programs. This enables users to use Enzyme to
perform various algorithms such as back-propagation in ML
or scientific simulation on existing code for any language that lowers to LLVM.

While this functions for any frontend that emits LLVM IR, it may be desirable
to have closer integration between Enzyme and the frontend for the sake of
passing additional information and creating a better user experience.

This project would seek to integrate Enzyme and the Rust front end to provide
a nice user-experience for Rust programmers who want to use Enzyme
to enable high-performance automatic differentiation. This also potentially
involves integration of LLVM plugin support/custom codegen into rustc.
</p>

<p><b>Expected results:</b>
Creation of a custom type-checked linguistic construct in Rust for calling Enzyme.
Mechanisms for parsing Rust's Type information (represented as debug LLVM debug
info) directly into type analysis.
</p>

<p><b>Confirmed mentor:</b> <a href="mailto:wmoses@mit.edu">William Moses</a></p>
<p><b>Desirable skills:</b>
Good knowledge of C++ and Rust. Experience with Enzyme or automatic differentiation
would be nice, but can also be learned in the project.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="static_analyzer_profling">Clang Static Analyzer performance profiling</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<ul>
<li>
Chart how much time is spent in transfer functions – including (but not
limited to!) checker callbacks.
</li>
<li>
Add llvm Statistics and Timers for quickly obtaining precise and concise
dumps without external profilers. Statistics on state splits might be
particularly interesting!
</li>
<li>
Measure time spent analyzing specific stack frames. Say, how much time
do we spend inlining <tt>std::string</tt> methods? This time could be
saved if we add custom models for these methods instead.
</li>
</ul>
</p>

<p><b>Confirmed mentor:</b> Artem Dergachev</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="static_analyzer_constraint_solver">Clang Static Analyzer constraint solver improvements</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
CSA has a small in-house constraint solver, it is pretty trivial, but super
fast. The goal is to support range-based logic for some of the symbolic
operators, while keeping it linear. Additionally, a unit-test framework
can be designed specifically for testing constraint solvers (right now it’s
tested rather awkwardly). This project has a couple of interesting
properties. It can be segmented into small chunks, and each of these
chunks has a non-trivial solution. It might introduce you to a world of
solvers (it is a good idea to check your ideas with some heavy-weight
solver such as z3). And because the existing solver is simple, there is a
myriad of possible extensions to try.
</p>

<p><b>Confirmed mentor:</b> Valeriy Savchenko</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="lldb_diagnostics">A structured approach to diagnostics in LLDB</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
<ul>
<li>
Design and integrate a new diagnostic abstraction (similar to
clang::Diagnostic) to report errors, warnings and notes in a structured
way.
</li>
<li>
Allow us to differentiate between bugs (unexpected errors) and things
the debugger simply doesn’t know (expected errors). Be smart about
printing global errors only once. Have the ability of being verbose and
have additional metadata (source location, DWARF unit, object file, etc,
depending on the type of error and where it originated). </li>
<li>
Should be compatible and tightly integrated with the existing classes,
such as the Status and CommandReturnObject.
</li>
</ul>
</p>

<p><b>Confirmed mentor:</b>
<a href="mailto:teemperor@gmail.com,jonas@devlieghere.com?subject=[GSoC]%20LLDB%20Diagnostics">Jonas Devlieghere and Raphael Isemann</a></p>
</div>

<!-- *********************************************************************** -->
aslUnsubmitted Not Done Reply Inline Actions I think it does make sense to keep link to old projects as this might be a good guidance for the students what to expect asl: I think it does make sense to keep link to old projects as this might be a good guidance for…
tonicAuthorUnsubmitted Done Reply Inline Actions Can I add links to the GSOC participation from previous years to the new GSOC landing page? At the bottom after useful links I can link to each official GSOC page that lists the projects that were successful. tonic: Can I add links to the GSOC participation from previous years to the new GSOC landing page? At…
<div class="www_sectiontitle">
<a name="gsoc20">Google Summer of Code 2020</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>
LLVM participation in Google Summer of Code 2020 was very successful and resulted
in many interesting projects contributed to LLVM. For the list of accepted and
completed projects, please take a look into Google Summer of Code
<a href="https://summerofcode.withgoogle.com/archive/2020/organizations/5902726635978752/">
website.</a>
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>LLVM</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_ipo">Improve inter-procedural analyses and optimizations</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on IRC)
if it sounds interesting.

During the GSoC'19 we build the Attributor framework to improve the
inter-procedural capabilities of LLVM. This is useful on its own but
especially in situations where inlining is impossible or undesirable.

In this GSoC project we will look at capabilities not yet available in the
Attributor and for the potential to connect the Attributor with existing
intra- and inter-procedural optimizations.

In this project there is a lot of freedom to determine the actual tasks but
we will provide a pool of smaller and medium sized tasks that can be chosen
from as well.
</p>

<p><b>Preparation resources:</b> The Attributor YouTube videos from the
LLVM Developers Meeting 2019 and the recording of the IPO panel from the same
meeting. The Attributor framework as well as other existing inter-procedural
analyses and optimizations in LLVM.</p>

<p><b>Expected results:</b> Measurable better IPO, especially visible in cases
where inlining is not an option or undesirable.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert</p>
<p><b>Desirable skills:</b> Intermediate knowledge of C++, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_par">Improve parallelism-aware analyses and optimizations</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
This is a short description, please reach out to Johannes (jdoerfert on IRC)
if it sounds interesting.

With the OpenMPOpt pass (<a href='https://reviews.llvm.org/D69930'>under
review</a>) we started to teach the LLVM optimization pipeline about
OpenMP parallelism encoded as OpenMP runtime calls.

In this GSoC project we will look at capabilities not yet available in the
OpenMPOpt pass and for the potential to connect existing intra- and
inter-procedural optimizations, e.g. the Attributor.

In this project there is a lot of freedom to determine the actual tasks but
we will provide a pool of smaller and medium sized tasks that can be chosen
from as well.
</p>

<p><b>Preparation resources:</b> The "Optimizing Indirections, using
abstractions without remorse" video on YouTube from the LLVM Developers
Meeting 2018. The paper "Compiler Optimizations for OpenMP" and "Compiler
Optimizations For Parallel Programs" both by J. Doerfert and H. Finkel (the
slides for these are potentially even more useful).</p>

<p><b>Expected results:</b> Measurable better performance or program analysis
results for parallel programs with a focus on OpenMP.</p>

<p><b>Confirmed Mentor:</b> Johannes Doerfert</p>
<p><b>Desirable skills:</b> Intermediate knowledge of C++, self motivation.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_dbg_invariant">Make LLVM passes debug info invariant</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Generating debug information is one of the fundamental tasks a compiler
typically fulfills. It is clear that executable generated code should not
depend on the presence of debug information.
<br><br>
Unfortunately there are known cases in LLVM were code generation differs
depending on whether debug information is enabled (`-g`) or not. These kind
of bugs can lead to bad debug experience ranging from unexpected execution
behaviour to the point of programs running fine in debug mode while crashing
without debug information.
<br><br>
The issue has likely not a single cause but is triggered during different
passes on different architectures. One such reason is the insertion of Call
Frame Information (CFI) in the compiler backend during frame lowering and
other later passes. The presence of CFI instructions seems to change
instruction scheduling which therefore leads to different generated code.
</p>

<p><b>Preparation resources:</b>
<ul>
<li>
<a href="https://llvm.org/PR37728">PR37728</a> is a
meta-bug that collects several related issues of differing codegen.
</li>
<li>
<a href="https://llvm.org/PR37240">PR37240</a> is a
bug discussing the CFI issue mentioned above.
</li>
<li>
The following
<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-September/135433.html">
RFC</a> discusses some possible mitigation strategies and gives some
background information on the CFI issue.
</li>
</ul>
</p>
<p><b>Expected results:</b>
<ul>
<li>
Write some tooling based on existing scripts to automatically generate
examples of differing codegen. This is intended as a starting task to get
to know the existing LLVM tools, learn to read LLVM's internal outputs etc.
</li>
<li>
Choose one or more (depending on the difficulty) bugs that cause codegen
differences and try to provide patches to fix them. We would be
particularly interested in the mentioned CFI issue but working on some of
the other related bugs is also absolutely fine.
</li>
</ul>
</p>

<p><b>Confirmed Mentors:</b> Paul Robinson and David Tellenbach</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++, some familarity with general computer
architecture, some familarity with the x86 or Arm/AArch64 instruction set.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_mergesim">Improve MergeFunctions to incorporate MergeSimilarFunction patches and ThinLTO Support</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b> MergeSimilarFunctions pass is able to
merge not just identical functions, but also functions with small differences in
their instructions to reduce code size. It does this by inserting control flow
and an additional argument in the merged function to account for the
differences.

This work was presented at
the <a href="http://llvm.org/devmtg/2013-11/#talk3">LLVM Dev Meeting in
2013</a> A more detailed description was published in a paper at
<a href="http://dl.acm.org/citation.cfm?id=2597811">LCTES 2014</a>. The code
was released to the community at the time. Meanwhile, the pass has been in
production use at QuIC for the past few years and has been actively
maintained internally. In order to magnify the impact of
MergeSimilarFunctions, it has been ported to ThinLTO and the patches have
been upstreamed (see stack of 5 patches mentioned below). But instead of
replacing the existing MergeFunctions pass in LLVM-upstream the community
suggested we improve the existing one with the ideas from
MergeSimilarFunctions. And then leverage the ThinLTO on top of that. The
MergeSimilarFunction used in ThinLTO gives impressive code size reduction
across a wide range of workloads and the work was presented at
<a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk2">LLVM-dev
2018</a>. The LLVM project would greatly benefit from this code size
optimization as most embedded systems (think SmartPhones) applications are
constrained on code-size.
</p>
<p><b>Preparation resources:</b>
<ul>
<li>
Stack of patches:
<ul>
<li>
<a href="https://reviews.llvm.org/D52896">MergeSimilarFunctions 1/n: a code size pass to merge functions with small differences</a>
</li>
<li>
<a href="https://reviews.llvm.org/D52898">[Porting MergeSimilarFunctions 2/n] Changes to DataLayout</a>
</li>
<li>
<a href="https://reviews.llvm.org/D52966">[Merge SImilar Function ThinLTO 3/n] Add hash code to function summary</a>
</li>
<li>
<a href="https://reviews.llvm.org/D53253">[Merge SImilar Function ThinLTO 4/n] Make merge function decisions before the thin-lto stage</a>
</li>
<li>
<a href="https://reviews.llvm.org/D53254">[Merge SImilar Function ThinLTO 5/n] Set up similar function to be imported</a>
</li>
</ul>
The paches can be easily applied to LLVM-trunk and would give a developer a decent head start ;).
</li>
<li>List of llvm-dev mailing list posts on previous discussions around Merge Functions
<ul>
<li><a href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129835.html">Link1</li>
<li><a href="http://lists.llvm.org/pipermail/llvm-dev/2019-March/131066.html">Link2</li>
<li><a href="http://lists.llvm.org/pipermail/llvm-dev/2019-February/129863.html">Link3</li>
<li><a href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129832.html">Link4</li>
</ul>
</li>
<li>
<a href="http://dl.acm.org/citation.cfm?id=2597811">The original paper: LCTES 2014</a>
</li>
<li>
<a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk2">Video and slides of the presentation</a>
</li>
</ul>
</p>
<p><b>Expected results:</b>
<ul>
<li>
Improve MergeFunctions to have feature parity with MergeSimilarFunctions.
</li>
<li>
Enable MergeFunctions to ThinLTO.
</li>
</ul>
</p>

<p><b>Confirmed Mentors:</b>Aditya Kumar (hiraditya on IRC and phabricator), JF Bastien (jfb on phabricator)</p>

<p><b>Desirable skills:</b>
Course on compiler design, SSA Representation,
Intermediate knowledge of C++, Familiarity with LLVM Core.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_dwarf_yaml2obj">Add DWARF support to yaml2obj</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
LLVM provides a tool called yaml2obj which coverts a YAML document into an
object file, for various different file formats such as ELF, COFF and
Mach-O, along with obj2yaml which does the inverse. The tool is commonly
used to test parts of LLVM, as YAML is often easier to use to describe an
object file than raw assembly and more maintainable than a pre-built binary.
DWARF is a debugging file format commonly used by LLVM. Many of the tests
for LLVM’s DWARF emission are written in assembly, but it would be nicer to
write them in YAML. However, yaml2obj does not properly support emission of
DWARF sections. This project is to add functionality to yaml2obj to make
writing test inputs for DWARF tests simpler, particularly for ELF objects.
</p>

<p><b>Preparation resources:</b>
Reading up on the DWARF file format will be useful, in particular the
standards available at http://dwarfstd.org/Download.php. Also, familiarising
yourself with the basics of the ELF file format, as described here
https://www.sco.com/developers/gabi/latest/contents.html, may be beneficial.
</p>
<p><b>Expected results:</b>
The ability to use yaml2obj to generate DWARF sections for object files.
Particularly important is ensuring the input YAML can be more easily
understood than the equivalent assembly.
</p>

<p><b>Confirmed Mentors:</b> James Henderson</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_hotcold">Improve hot cold splitting to aggressively outline small blocks</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b> Hot Cold Splitting in LLVM is an IR level
function splitting transformation. The goal of hot/cold splitting is to improve
the memory locality of code and helps reduce startup working set. The splitting pass
does this by identifying cold blocks and moving them into separate functions. Because it
is implemented at the IR level all the back end target benefit from it.

It is a relatively new optimization and it was recently presented at
the <a href="https://llvm.org/devmtg/2019-10/talk-abstracts.html#tech8">LLVM Dev Meeting in
2019</a> and the slides are <a href="https://llvm.org/devmtg/2019-10/slides/Kumar-HotColdSplitting.pdf">here</a>
Because most of the benefit comes from outlining small blocks e.g., __assert_rtn. The goal of this project
is to identify potential blocks via static analysis e.g., exception handling code, optimizing personality functions.

Use cost-model to ensure outlining reduces the code size of the caller, use tail call whenever appropriate to save
instructions.

</p>
<p><b>Preparation resources:</b>
<ul>
<li>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129606.html">Update on hot cold splitting</a>
</li>
<li>
The following two papers provide earlier work on hot cold splitting. While these papers are a good start, LLVM's
HCS has completely different implementation in two aspects a) It is implemented at IR level and outlines basic
blocks as function rather than naked branches. b) It is based on regions and outlines a set of basic blocks.
<ul>
<li>
<a href="http://pages.cs.wisc.edu/~fischer/cs701.f05/code.positioning.pdf">Original paper on hot cold splitting by
Pettis and Hansen.</a>Section 5 on procedure splitting is interesting one. It has nice examples ;) to help
understand why HCS works.
</li>
<li>
<a href="https://www.cs.cmu.edu/afs/cs/academic/class/15745-s07/www/papers/p80-cohn.pdf">Paper on hot cold
splitting</a> The paper provides some details on one approach to split functions. This is helpful to get a
different perspective and may help get new ideas.
</li>
</ul>
</li>
<li>
<a href="https://llvm.org/devmtg/2019-10/talk-abstracts.html#tech8">Video and slides of the presentation</a>
</li>
</ul>
</p>
<p><b>Expected results:</b>
<ul>
<li>
Improve Hot Cold Splitting to detect and outline cold blocks from program via static analysis or profile
information. Use appropriate cost model to weigh benefit of HCS.
In case compile time overhead becomes quadratic, come up with a cost model to detect when quadratic behavior
gets triggered and bail out based on a compiler flag.
</li>
</ul>
</p>

<p><b>Confirmed Mentors:</b>Aditya Kumar (hiraditya on IRC and phabricator)</p>

<p><b>Desirable skills:</b>
Course on compiler design, SSA Representation,
Intermediate knowledge of C++, Familiarity with LLVM Core.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_pass_order">Advanced Heuristics for Ordering Compiler Optimization Passes</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Selecting optimization passes for given application is very important but
non-trivial problem because of the huge size of the compiler transformation
space (incl. pass ordering). While the existing heuristics can provide high
performance code for certain applications, they cannot easily benefit a wide
range of application codes. The goal of the project is to learn the interplay
between LLVM transformation passes and code structures, then improve the
existing heuristics (or replace the heuristics with machine learning-based
models) so that the LLVM compiler can provide a superior order of the passes
customized per application.
</p>
<p><b>Expected results (possibilities):</b>
<ul>
<li>
Insights about (implicit) dependences between existing passes.
</li>
<li>
New pass pipelines (think -O3a, -O3b, ...) selectable by the user that tend to perform substantially better on certain kinds of programs.
</li>
<li>
An improved LLVM pass heuristic or new machine learning-based models that can select
the best order for LLVM transformation passes based on code structures.
</li>
</ul>
</p>

<p><b>Preparation resources:</b>
<ul>
<li>
HERCULES: Strong Patterns towards More Intelligent Predictive Modeling, Eunjung Park; Christos Kartsaklis; John Cavazos, IEEE ICPP’14
https://ieeexplore.ieee.org/abstract/document/6957226
</li>

<li>
Predictive Modeling in a Polyhedral Optimization Space, Eunjung Park, John Cavazos, Louis-Noël Pouchet, Cédric Bastoul, Albert Cohen & P. Sadayappan, IJPP’13
https://link.springer.com/article/10.1007/s10766-013-0241-1
</li>

<li>
Machine Learning in Compiler Optimization, Zheng Wang and Michael O’Boyle, IEEE Magazine 2018.
https://ieeexplore.ieee.org/document/8357388
</li>
</ul>
</p>

<p><b>Confirmed Mentors:</b>EJ Park, Giorgis Georgakoudis, Johannes Doerfert</p>

<p><b>Desirable skills:</b>
C++, Python, experience with LLVM and learning-based prediction preferable.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_ml_scc">Machine learning and compiler optimizations: using inter-procedural analysis to select optimizations</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Current machine learning models for compiler optimization select the best
optimization strategies for functions based on isolated per function analysis.
In this approach, the constructed models are not aware of any relationships
with other functions around it (callers or callees) which can be helpful to
decide the best optimization strategies for each function. In this project, we
want to explore the SCC (Strongly Connected Components) call graph to add
inter-procedural features in constructing machine learning-based models to find
the best optimization strategies per function. Moreover, we want to explore the
case that it is helpful to group strongly related functions together and
optimize them as a group, instead of per function.
</p>
<p><b>Expected results (possibilities):</b>
<ul>
<li>
Improved heuristics for existing (inter-procedural) passes, e.g. to weight inlining versus function cloning based on code features.
</li>
<li>
Machine learning models to select the best optimizations using code features
and inter-procedural analysis. This model can be used for functions in
isolation or groups of functions, e.g., CGSCCs.
</li>
</ul>
</p>

<p><b>Preparation resources:</b>
<ul>
<li>
HERCULES: Strong Patterns towards More Intelligent Predictive Modeling, Eunjung Park; Christos Kartsaklis; John Cavazos, IEEE ICPP’14
https://ieeexplore.ieee.org/abstract/document/6957226
</li>

<li>
Predictive Modeling in a Polyhedral Optimization Space, Eunjung Park, John Cavazos, Louis-Noël Pouchet, Cédric Bastoul, Albert Cohen & P. Sadayappan, IJPP’13
https://link.springer.com/article/10.1007/s10766-013-0241-1
</li>

<li>
Machine Learning in Compiler Optimization, Zheng Wang and Michael O’Boyle, IEEE Magazine 2018.
https://ieeexplore.ieee.org/document/8357388
</li>
</ul>
</p>

<p><b>Confirmed Mentors:</b>EJ Park, Giorgis Georgakoudis, Johannes Doerfert</p>

<p><b>Desirable skills:</b>
C++, Python, experience with LLVM and learning-based prediction preferable.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_postdominators"></a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
There is currently no easy way to use the result of
PostDominatorTreeAnalysis in a loop pass, as PostDominatorTreeAnalysis is a
function analysis, and it is not included in LoopStandardAnalysisResults. If one adds
PostDominatorTreeAnalysis in LoopStandardAnalysisResults, then all loop passes
need to preserve it, meaning that all loop passes need to make sure the result is up to
date. In this project, we want to modify some commonly used utilities to generate a
list of updates, which can be consume by different updaters, e.g. DomTreeUpdater to
update DominatorTree and PostDominatorTree, and MSSAU to update MemorySSA,
etc, instead of only updating the DominatorTree. In additional, we want to change
existing loop passes to preserve the PostDominatorTree. Finally, adding
PostDominatorTree in LoopStandardAnalysisResults.
</p>
<p><b>Expected results (possibilities):</b>
PostDominatorTree added in LoopStandardAnalysisResults, and
can be used by loop passes. More common utilities change to generate list of updates
to be easily obtained by different updaters.
</p>
<p><b>Confirmed Mentors:</b>
Whitney Tsang, Ettore Tiotto, Bardia Mahjour
</p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++, self-motivation.
</p>
<p><b>Preparation resources:</b>
<a href="https://reviews.llvm.org/rL336163"></a>
<a href="http://llvm.org/doxygen/classllvm_1_1DomTreeUpdater.html"></a>
<a href="https://llvm.org/doxygen/classllvm_1_1PostDominatorTreeAnalysis.html"></a>
<a href="http://llvm.org/doxygen/structllvm_1_1LoopStandardAnalysisResults.html"></a>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_loopnest">Create LoopNest Pass</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Currently if you want to write a pass that works on a loop
nest, you have to pick from either a function pass or a loop pass. If you chose to write
it as a function pass, then you lose the ability to add loops dynamically back to the
pipeline. If you decide to write it as a loop pass, then you are wasting compile time to
traverse to your pass and return right away when the given loop is not the outermost
loop. In this project, we want to create a LoopNestPass, where transformations
intended for loop nest can inherit from it, and have the same ability as the LoopPass to
dynamically add loops to the pipeline. In addition, create all the adaptors requires to
add loop nest passes at different points of the pass builder.
</p>
<p><b>Expected results (possibilities):</b>
Transformations/Analyses can be written as LoopNestPass,
without compromising compile time or usability.
</p>
<p><b>Confirmed Mentors:</b>
Whitney Tsang, Ettore Tiotto
</p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++, self-motivation.
</p>
<p><b>Preparation resources:</b>
<a href="https://reviews.llvm.org/D68789"</a>
<a href="https://llvm.org/doxygen/classllvm_1_1PassBuilder.html"</a>
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_instdump">Instruction properties dumper and checker</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
TableGen is flexible and allow the end-user to define and set common properties of
records (instructions). Every target has dozens or hundreds of such instruction
properties. As target code evolve, the td files become more and more complicated,
it become harder to see whether the setting of some properties is necessary, even
correct or not. eg: whether hasSideEffects property is correctly set on all
instructions?

One can manually search through the TableGen-generated files; or write some
script to run TableGen and matching the output for some specific properties, but a
standalone utility that can dump and check instruction properties
systematically (eg: also allow target to define some verification rules) might be
better from a build-process-management standpoint. This can help to find quite
some hidden bugs and hence improve the overall codegen code quality. In
addition, the utility can be used to write regression tests for instruction
properties, which will increase the quality and precision of LLVM's
regression tests.
</p>
<p><b>Expected results (possibilities):</b>
A standalone llvm tool or utility that can dump and check instruction properties systematically
</p>
<p><b>Confirmed Mentors:</b>
Hal Finkel, Jinsong Ji , Qingshan Zhang
</p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++, self-motivation.
</p>
</div>

<!-- *********************************************************************** -->

<div class="www_subsubsection">
<a name="llvm_movecode">Unify ways to move code or check if code is safe to be moved</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Determining whether it is safe to move code around is
implemented in several transformations in LLVM (e.g. canSinkOrHoistInst in LICM,
or makeLoopInvariant in Loop). Each of these implementations may return different
results for a given query, making code motion safety checks inconsistent and
duplicated. On the other hand, the mechanism for doing the actual code motion is also
different in each transformation. Code duplication causes maintenance problems and
increases the time taken to write new transformation. In this project, we want to first
identify all the existing ways in loop transformations (could be function or loop pass)
to check if code is safe to move, and to move code, and create a standardize way to do
so.
</p>
<p><b>Expected results (possibilities):</b>
A standardize/superset of all the existing ways in loop
transformations of checking if code is safe to be moved and to move <code class=""></code>
</p>

<p><b>Confirmed Mentors:</b>
Whitney Tsang, Ettore Tiotto, Bardia Mahjour
</p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++, self-motivation.
</p>
<p><b>Preparation resources:</b>
<a href="https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Transforms/Utils/CodeMoverUtils.h"></a>
<a href="https://llvm.org/doxygen/LICM_8cpp_source.html"></a>
<a href="https://llvm.org/doxygen/classllvm_1_1Loop.html"></a>
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>MLIR</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>All the items in the list of
<a href="https://mlir.llvm.org/getting_started/openprojects/">open projects</a>
are opened to GSOC. Feel free to propose your own ideas as well on
<a href="https://llvm.discourse.group/c/llvm-project/mlir">Discourse</a>.
</p></div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="clang-sa-cplusplus-checkers">Find null smart pointer dereferences
with the Static Analyzer</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b>
The Clang Static Analyzer already knows how to prevent crashes caused by
null pointer dereference in arbitrary code, however it often "gives up"
when the code is too complicated. In particular, implementation details
of C++ standard classes, even simple ones such as smart pointers
or optionals, may be too convoluted for the Analyzer to fully understand.
Moreover, the exact behavior depends on which implementation of
the Standard Library is used (e.g., GNU libstdc++ or LLVM's own libc++).
</p>
<p>
We can enable the Analyzer to find more bugs in modern C++ code
by teaching it explicitly about the behavior of C++ standard classes,
and therefore skipping the whole process in which the Analyzer
tries to understand all the implementation details on its own.
For example, we could teach it that a default-constructed smart pointer
is null, and any attempt to dereference it would result in a crash.
The project would therefore consist in manually providing implementations
for various methods of standard classes.
</p>

<p><b>Expected results: </b>
We want the Static Analyzer to emit warnings when a null smart pointer
dereference would occur in the code. For example:
<pre>
#include <memory>

int foo(bool flag) {
std::unique_ptr<int> x; <i>// note: Default constructor produces a null unique pointer;</i>

if (flag) <i>// note: Assuming 'flag' is false;</i>
return 0; <i>// note: Taking false branch</i>

return *x; <i>// warning: Dereferenced smart pointer 'x' is null.</i>
}
</pre>
We should be able to cover at least one class fully, for example, <tt>std::unique_ptr</tt>,
and then see if we can generalize our results to other classes, such as <tt>std::shared_ptr</tt>
or the C++17 <tt>std::optional</tt>.
</p>


<p><b>Confirmed Mentor:</b> Artem Dergachev, Gábor Horváth</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++.
</p>
</div>


<!-- *********************************************************************** -->
<div class="www_subsection">
<a>LLDB</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="lldb-autosuggestions">Support autosuggestions in LLDB's command line</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b> LLDB's command line offers several convenience
features that are inspired by features of UNIX shells such as tab completions or a command history.
One feature that is not implemented yet are 'autosuggestions'. These are suggestions
for possible commands that the user might want to type, but unlike tab completions they
are displayed directly behind the cursor while the user is typing a command. A good demonstration
how this could look like are the autosuggestions implemented in <a href="https://fishshell.com">fish shell</a>.
</p>
<p>
This project is about implementing autosuggestions in LLDB's editline-based command shell.
</p>
<p><b>Confirmed Mentor:</b>
<a href="mailto:teemperor@gmail.com,jonas@devlieghere.com?subject=[GSoC]%20Autosuggestions">Jonas Devlieghere and Raphael Isemann</a></p>
<p><b>Desirable skills:</b>
Intermediate knowledge of C++.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="lldb-more-completions">Implement the missing tab completions for LLDB's command line</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b> LLDB's command line offers several convenience
features that are inspired by features of UNIX shells such as tab completions for commands.
These tab completions are implemented by a completion engine that is not only used by the
command line interface of LLDB, but also by graphical interfaces for LLDB such as IDEs.

While the tab completions in LLDB are really useful, they are currently not implemented for
all commands and their respective arguments. This project is about implementing the remaining
completions for the commands in LLDB which will greatly improve the user experience of LLDB.
Improving existing completions is also part of the project.

Note that the completions are not static list of strings but often require inspecting and
understanding the internal state of LLDB. As LLDB commands and their tab completions cover
all aspects of LLDB, this project offers a great way to get an overview of all the functionality
in LLDB.
</p>
<p><b>Confirmed Mentor:</b><a href="mailto:teemperor@gmail.com?subject=[GSoC]%20Completions">Raphael Isemann</a></p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++.
</p>
</div>


<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="lldb-reimplement-lldb-cmdline">Reimplement LLDB's command-line commands
using the public SB API.</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b> Just as LLVM is a library to
build compilers, LLDB is a library to build debuggers. LLDB vends
a stable, public SB API. Due to historic reasons the LLDB command
line interface is currently implemented on top of LLDB's private
API and it duplicates a lot of functionality that is already
implemented in the public API. Rewriting LLDB's command line
interface on top of the public API would simplify the
implementation, eliminate duplicate code, and most importantly
reduce the testing surface.
</p>
<p>
This work will also provide an opportunity to clean up the SB API
of commands that have accrued too many overloads over time and
convert them to make use of option classes to both gather up all
the variants and also future-proof the APIs.
</p>
<p><b>Confirmed Mentor:</b>Adrian Prantl and Jim Ingham</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="lldb-batch-testing">Add support for batch-testing to the LLDB
testsuite.</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b>One of the tensions in the
testsuite is that spinning up a process and getting it to some
point is not a cheap operation, so you'd like to do a bunch of
tests when you get there. But the current testsuite bails at the
first failure, so you don't want to do many tests since the
failure of one fails all the others. On the other hand, there are
some individual test assertions where the failure of the assertion
<em>should</em> cause the whole test to fail. For example, if you
fail to stop at a breakpoint where you want to check some variable
values, then the whole test should fail. But if your test then
wants to check the value of five independent locals, it should be
able to do all five, and then report how many of the five variable
assertions failed. We could do this by adding <em>Start</em>
and <em>End</em> markers for a batch of tests, do all the tests in
the batch without failing the whole test, and then report the
error and fail the whole test if appropriate. There might also be
a nice way to do this in Python using scoped objects for the test
sections.
</p>
<p><b>Confirmed Mentor:</b> Jim Ingham</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of Python.
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_sectiontitle">
<a name="gsoc19">Google Summer of Code 2019</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>Google Summer of Code 2019 contributed a lot to the LLVM project. For the list of
accepted and completed projects, please take a look into Google Summer of Code
<a href="https://summerofcode.withgoogle.com/archive/2019/organizations/5682474363912192/">website.
</a></p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsection">
<a>LLVM</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="debuginfo_codegen_mismatch">Debug Info should have no
effect on codegen</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project:</b>
Adding Debug Info (compiling with `clang -g`) shouldn't change the
generated code at all. Unfortunately we have bugs. These are usually not
too hard to fix and a good way to discover new part of the codebase!
We suggest building object files both ways and disassembling the
text sections, which will give cleaner diffs than comparing .s files.
</p>

<p><b>Expected results:</b> Reduced test cases, bug reports with analysis
(e.g., which pass is responsible), possibly patches.</p>

<p><b>Confirmed Mentor:</b> Paul Robinson</p>
<p><b>Desirable skills:</b> Intermediate knowledge of C++, some familiarity
with x86 or ARM instruction set.</p>
</div>


<!-- *********************************************************************** -->
<div class="www_subsection">
<a>Clang</a>
</div>
<!-- *********************************************************************** -->

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="clang-astimporter-fuzzer">Implement an ASTImporter fuzzer</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b>
Clang contains an ASTImporter which allows moving declarations and
statements from one Clang AST to another. This is for example used for
static analysis across translation units and in LLDB's expression
evaluator.
</p>
<p>
The current ASTImporter works as intended when moving simple C code from
one AST to another. However, more complicated declarations such as C++'s
OOP features and templates are not fully implemented and can cause crashes
or invalid AST nodes. The bug reports related to these crashes are often
filed against LLDB's expression evaluator and are rarely submited with a
minimal reproducer. This makes improving ASTImporter a time-consuming and
tedious task.
</p>
<p>
This project is about writing a fuzzer to proactively discover these
ASTImporter bugs and provide minimal reproducers which make understanding
and fixing the underlying bug easier.
</p>
<p>
A possible implementation of such a fuzzer and driver could look like this:

<ul>
<li>Generate some source code that can be imported (either fully randomly
or based on existing source code from a user-given code corpus).</li>
<li>Import randomly a few declarations from this AST. The AST in which
they are imported to can already be populated with declarations.</li>
<li>Run Clang's code generator over our imported AST.</li>
<li>If we hit an assert during the import or CodeGen steps we probably
found an ASTImporter bug.</li>
<li>The fuzzer driver should now reduce the size of the source code
until it is as small as possible and still reproduces the crash (e.g.
by running Creduce with an automatically generated test script).</li>
<li>The reproducer should now be stored in a format so that it can just be
copied into Clang's regression test suite for the ASTImporter (see
the <a href="https://github.com/llvm/llvm-project/tree/master/clang/test/Import">clang/test/Import/</a> directory).
The reproducer must still reproduce the found bug when run as part
of the test suite.
</li>
</ul>
This is just one possible approach and students are welcome to submit their
own ideas on how the fuzzer should operate. Approaches that allow to
automatically verify more aspects of the imported AST (e.g. the source
locations of AST nodes, size of RecordDecls) are encouraged. The fuzzer and
driver should be implemented in C++ and/or Python.
</p>
<p><b>Confirmed Mentor:</b> Raphael Isemann, Shafik Yaghmour</p>
<p><b>Desirable skills:</b> Intermediate knowledge of C++.</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="improve-autocompletion">Improve shell autocompletion for Clang</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Description of the project: </b> Clang has a newly implemented autocompletion feature which details can be found at <a href="http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html">LLVM blog</a>. We would like to improve this by adding more flags to autocompletion, supporting more shells (currently it supports only bash) and exporting this feature to other projects such as llvm-opt. Accepted student will be working on Clang Driver, LLVM Options and shell scripts.
</p>

<p><b>Expected Results:</b> Autocompletion working on bash and zsh, support llvm-opt options.</p>

<p><b>Confirmed Mentor:</b> Yuka Takahashi and Vassil Vassilev</p>

<p><b>Desirable skills:</b>
Intermediate knowledge of C++ and shell scripting
</p>
</div>

<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="header-clang-diagnostic">Improve Clang Diagnostics</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p><b>Decription:</b>
Clang diagnostics (warnings and errors) issues to the programmer are a critical
feature of the compiler. Great diagnostics can have a signifiant impact on the
user experience of the compiler and increase their productivity.
</p>

<p><a href="https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9/">
Recent improvements in GCC 9.0</a> show that there is significant headroom to
improve diagnostics (and user interactions in general). It would be a very
impactful project to survey and identify all the possible improvements to clang
on this topic, and start resigning the next generation of our diagnostics.
</p>

<p><b>Desirable skills:</b> C++ coding experience</p>
</div>

<!-- *********************************************************************** -->
<div class="www_sectiontitle">
<a name="gsoc18">Google Summer of Code 2018</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>Google Summer of Code 2018 contributed a lot to the LLVM project. For the list of
accepted and completed projects, please take a look into Google Summer of Code
<a href="https://summerofcode.withgoogle.com/archive/2018/organizations/5263452624912384/">website.
</a></p>
</div>

<!-- *********************************************************************** -->
<div class="www_sectiontitle">
<a name="gsoc17">Google Summer of Code 2017</a>
</div>
<!-- *********************************************************************** -->

<div class="www_text">
<p>Google Summer of Code 2017 contributed a lot to the LLVM project. For the list of
accepted and completed projects, please take a look into Google Summer of Code
<a href="https://summerofcode.withgoogle.com/archive/2017/organizations/6215410651234304/">website.
</a></p>
</div>

<!-- *********************************************************************** -->
<div class="www_sectiontitle">
<a name="what">What is this?</a>		<a name="what">What is this?</a>
</div>		</div>
<!-- *********************************************************************** -->		<!-- *********************************************************************** -->

<div class="www_text">		<div class="www_text">

<p>This document is meant to be a sort of "big TODO list" for LLVM. Each		<p>This document is meant to be a sort of "big TODO list" for LLVM. Each
project in this document is something that would be useful for LLVM to have, and		project in this document is something that would be useful for LLVM to have, and
▲ Show 20 Lines • Show All 670 Lines • Show Last 20 Lines

This is an archive of the discontinued LLVM Phabricator instance.

Add GSOC landing page with instructions for GSOC students.Needs ReviewPublic

Details

Diff Detail

Event Timeline

Revision Contents

Diff 415159

GSOC.html

OpenProjects.html

Add GSOC landing page with instructions for GSOC students.
Needs ReviewPublic