forked from llvm/llvm-www
-
Notifications
You must be signed in to change notification settings - Fork 0
/
OpenProjects.html
executable file
·5506 lines (4751 loc) · 256 KB
/
OpenProjects.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!--#include virtual="header.incl" -->
<div class="www_sectiontitle">Open LLVM Projects</div>
<ul>
<li>Google Summer of Code Ideas & Projects
<ul>
<li>
<a href="#gsoc24">Google Summer of Code 2024</a>
<ul>
<li><b>LLVM Core</b>
<ul>
<li><a href="#remove_ub_tests">Remove undefined behavior from tests</a></li>
<li><a href="#spirv_tablegen">Automatically generate TableGen file for SPIR-V instruction set</a></li>
<li><a href="#bitstream_cas">LLVM bitstream integration with CAS (content-addressable storage)</a></li>
<li><a href="#three_way_comparison">Add 3-way comparison intrinsics</a></li>
<li><a href="#llvm_www">Improve the LLVM.org Website Look and Feel</a></li>
</ul>
<li><a href="http://clang.llvm.org/"><b>Clang</b></a>
<ul>
<li><a href="#clang-repl-out-of-process">Out-of-process execution for clang-repl</a>
<li><a href="#clang-plugins-windows">Support clang plugins on Windows</a>
<li><a href="#clang-on-demand-parsing">On Demand Parsing in Clang</a>
</ul>
<li><a href="http://lldb.llvm.org/"><b>LLDB</b></a>
<ul>
<li><a href="#rich-disassembler-for-lldb">Rich disassembler for LLDB</a>
</ul>
<li><a href="http://openmp.llvm.org/"><b>(OpenMP) Offload</b></a>
<ul>
<li><a href="#gpu-delta-debugging">GPU Delta Debugging</a>
<li><a href="#offload-libcxx">Offloading libcxx</a>
<li><a href="#parameter-tuning">The 1001 thresholds in LLVM</a>
<li><a href="#gpu-libc">Performance tuning the GPU libc</a>
<li><a href="#gpu-first">Improve GPU First</a>
</ul>
</ul>
</li>
<li>
<a href="#gsoc23">Google Summer of Code 2023</a>
<ul>
<li>
<b>LLVM Core</b>
<ul>
<li><a href="#llvm_new_jitlink_reopt">Re-optimization using JITLink</a></li>
<li><a href="#llvm_new_jitlink_backends">JITLink new backends</a></li>
<li><a href="#llvm_improving_compile_times">Improving compile times</a></li>
<li><a href="#llvm_addressing_rust_optimization_failures">Addressing Rust optimization failures</a></li>
<li><a href="#llvm_mlgo_latency_model">Better performance models for MLGO training</a></li>
<li><a href="#llvm_mlgo_passes_2023">Machine Learning Guided Ordering of Compiler Optimization Passes</a></li>
<li><a href="#llvm_map_value_to_src_expr">Map LLVM values to corresponding source-level expressions</a></li>
</ul>
</li>
<li><a href="http://clang.llvm.org/"><b>Clang</b></a>
<ul>
<li><a href="#clang-repl-out-of-process">Out-of-process execution for clang-repl</a>
<li><a href="#clang_analyzer_taint_analysis">Improve and Stabilize the Clang Static Analyzer's "Taint Analysis" Checks</a></li>
<li><a href="#clang-repl-autocompletion">Implement autocompletion in clang-repl</a>
<li><a href="#clang-modules-build-daemon">Modules build daemon: build system agnostic support for explicitly built modules</a></li>
<li><a href="#clang-extract-api-categories">ExtractAPI Objective-C categories</a></li>
<li><a href="#clang-extract-api-cpp-support">ExtractAPI C++ Support</a></li>
<li><a href="#clang-extract-api-while-building">ExtractAPI while building</a></li>
<li><a href="#clang-improve-diagnostics2">Improve Clang diagnostics</a></li>
<li><a href="#clang-tutorials-clang-repl">Tutorial development with clang-repl</a></li>
<li><a href="#clang-repl-wasm">Add WebAssembly Support in clang-repl</a></li>
</li>
</ul>
</li>
<li>
<b>LLD</b>
<ul>
<li><a href="#llvm_lld_embedded">LLD Linker Improvements for Embedded Targets</a></li>
</ul>
</li>
<li>
<b>MLIR</b>
<ul>
<li><a href="#llvm_mlir_presburger_opt">Optimizing MLIR’s Presburger library</a></li>
<li><a href="#llvm_mlir_query">Interactively query MLIR IR</a></li>
</ul>
</li>
<li>
<b>Code Coverage</b>
<ul>
<li><a href="#llvm_code_coverage">Support a hierarchical directory structure in generated coverage html reports</a></li>
<li><a href="#llvm_patch_coverage">Patch based test coverage for quick test feedback</a></li>
</ul>
</li>
<li>
<b>ClangIR</b>
<ul>
<li><a href="#clangir">Build and run SingleSource benchmarks using ClangIR</a></li>
</ul>
</li>
<li>
<b><a href="https://enzyme.mit.edu">Enzyme</a></b>
<ul>
<li><a href="#enzyme_tblgen_extension">Move additional Enzyme Rules to Tablegen</a></li>
</ul>
</li>
</ul>
</li>
<li>
<a href="#gsoc22">Google Summer of Code 2022</a>
<ul>
<li>
<b>LLVM Core</b>
<ul>
<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_instrumentaion_for_compile_time">Instrumentation of Clang/LLVM for Compile Time</a></li>
<li><a href="#llvm_lto_dependency_info">Richer symbol dependency information for LTO</a></li>
<li><a href="#llvm_mlgo_passes">Machine Learning Guided Ordering of Compiler Optimization Passes</a></li>
<li><a href="#llvm_mlgo_loop">Learning Loop Transformation Heuristics</a></li>
<li><a href="#llvm_module_inliner">Evaluate and Expand the Module-Level Inliner</a></li>
<li><a href="#llvm_undef_load">Remove undef: move uninitialized memory to poison</a></li>
<li><a href="#llvm_abi_export">Add ABI/API export annotations to the LLVM build</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>
<li><a href="#clang-sa-structured-bindings">Implement support for
C++17 structured bindings in the Clang Static Analyzer</a>
</li>
<li><a href="#clang-improve-diagnostics">Improve Clang Diagnostics</a>
</li>
</ul>
</li>
<li>
<a href="https://polly.llvm.org"><b>Polly</b></a>
<ul>
<li><a href="#polly_npm">Completely switch to new pass manager</a></li>
</ul>
</li>
<li>
<b><a href="https://enzyme.mit.edu">Enzyme</a></b>
<ul>
<li><a href="#enzyme_tblgen">Move Enzyme Instruction Transformation Rules to Tablegen</a></li>
<li><a href="#enzyme_vector">Vector Reverse-Mode Automatic Differentiation</a></li>
<li><a href="#enzyme_pm">Enable The New Pass Manager</a></li>
</ul>
</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>
</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>
</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>
<li><a href="#what">What is this?</a></li>
<li><a href="#subprojects">LLVM Subprojects: Clang and more</a></li>
<li><a href="#improving">Improving the current system</a>
<ol>
<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="#programs">Compile programs with the LLVM Compiler</a></li>
<li><a href="#llvmtest">Add programs to the llvm-test suite</a></li>
<li><a href="#benchmark">Benchmark the LLVM compiler</a></li>
<li><a href="#statistics">Benchmark Statistics and Warning System</a></li>
<li><a href="#coverage">Improving Coverage Reports</a></li>
<li><a href="#misc_imp">Miscellaneous Improvements</a></li>
</ol></li>
<li><a href="#new">Adding new capabilities to LLVM</a>
<ol>
<li><a href="#llvm_ir">Extend the LLVM intermediate representation</a></li>
<li><a href="#pointeranalysis">Pointer and Alias Analysis</a></li>
<li><a href="#profileguided">Profile-Guided Optimization</a></li>
<li><a href="#compaction">Code Compaction</a></li>
<li><a href="#xforms">New Transformations and Analyses</a></li>
<li><a href="#codegen">Code Generator Improvements</a></li>
<li><a href="#misc_new">Miscellaneous Additions</a></li>
</ol></li>
<li><a href="#using">Project using LLVM</a>
<ol>
<li><a href="#machinemodulepass">Add a MachineModulePass</a></li>
<li><a href="#encodeanalysis">Encode Analysis Results in MachineInstr IR</a></li>
<li><a href="#codelayoutjit">Code Layout in the LLVM JIT</a></li>
<li><a href="#fieldlayout">Improved Structure Splitting and Field Reordering</a></li>
<li><a href="#slimmer">Finish the Slimmer Project</a></li>
</ol></li>
</ul>
<div class="doc_author">
<p>Written by the <a href="/">LLVM Team</a></p>
</div>
<!-- *********************************************************************** -->
<div class="www_sectiontitle">
<a name="gsoc24">Google Summer of Code 2024</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p>
Welcome prospective Google Summer of Code 2024 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. More information and discussion about GSoC can be found in
<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>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="remove_ub_tests">Remove undefined behavior from tests</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
Many of LLVM's unit tests have been reduced automatically from larger tests.
Previous-generation reduction tools used undef and poison as placeholders
everywhere, as well as introduced undefined behavior (UB).
Tests with UB are not desirable because 1) they are fragile since in the
future the compiler may start optimizing more aggressively and break the
test, and 2) it breaks translation validation tools such as
<a href="https://github.com/AliveToolkit/alive2/">Alive2</a> (since it's
correct to translate a fuction that is always UB into anything).
<br />
The major steps include:
<ol>
<li>Replace known patterns such as branch on undef/poison, memory accesses
with invalid pointers, etc with non-UB patterns.</li>
<li>Use Alive2 to detect further patterns (by searching for tests that are
always UB).</li>
<li>Report any LLVM bug found by Alive2 that is exposed when removing
UB.</li>
</ol>
</p>
<p><b>Expected result:</b>
The majority of LLVM's unit tests will be free of UB.</p>
<p><b>Skills:</b>
Experience with scripting (Python or PHP) is required.
Experience with regular expressions is encouraged.
</p>
<p><b>Project size:</b> Either medium or large.</p>
<p><b>Difficulty:</b> Medium</p>
<p><b>Confirmed Mentor:</b> <a href="https://web.ist.utl.pt/nuno.lopes/">Nuno Lopes</a></p>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="spirv_tablegen">Automatically generate TableGen file for SPIR-V instruction set</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
The existing file that describes the SPIR-V instruction set in LLVM was
manually created and is not always complete or up to date. Whenever new
instructions need to be added to the SPIR-V backend, the file must be
amended. In addition, since it is not created in a systematic way, there are
often slight discrepancies between how an instruction is described in the
SPIR-V spec and how it is declared in the TableGen file. Since SPIR-V
backend developers often use the spec as a reference when developing new
features, having a consistent mapping between the specification and TableGen
records will ease development. This project proposes creating a script
capable of generating a complete TableGen file that describes the SPIR-V
instruction set given the JSON grammar available in the
KhronosGroup/SPIRV-Headers repository, and updating SPIR-V backend code to
use the new definitions. The specific method used for translating the JSON
grammar to TableGen is left up to the discretion of the applicant, however,
it should be checked into the LLVM repository with well-documented
instructions to replicate the translation process so that future maintainers
will be able to regenerate the file when the grammar changes. Note that the
grammar itself should remain out-of-tree in its existing separate
repository.
</p>
<p><b>Expected result:</b>
<ul>
<li>The SPIR-V instruction set's definition in TableGen is replaced with
one that is autogenerated.</li>
<li>A script and documentation are written that support regenerating the
definitions as needed given the JSON grammar of the SPIR-V instruction
set.</li>
<li>Usage of the SPIR-V instruction set in the SPIR-V backend updated to
use the new autogenerated definitions.</li>
</ul>
</p>
<p><b>Skills:</b>
Experience with scripting and an intermediate knowledge of C++. Previous
experience with LLVM/TableGen is a bonus but not required.
</p>
<p><b>Project size:</b> Medium (175 hour)</p>
<p><b>Confirmed Mentors:</b>
<a href="https://github.com/sudonatalie/">Natalie Chouinard</a>,
<a href="https://github.com/keenuts/">Nathan Gauër</a></p>
<p><b>Discourse:</b>
<a href="https://discourse.llvm.org/t/clang-automatically-generate-tablegen-file-for-spir-v-instruction-set/76369">URL</a>
</p>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="bitstream_cas">LLVM bitstream integration with CAS (content-addressable storage)</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
The LLVM bitstream file format is used for serialization of intermediate
compiler artifacts, such as LLVM IR or Clang modules. There are situations
where multiple bitstream files store identical information, and this
duplication leads to increased storage requirements.
<br><br>
This project aims to integrate the LLVM CAS library into the LLVM bitstream
file format. If we factor out the frequently duplicated part of a bitstream
file into a separate CAS object, we can replace all copies with a small
reference to the canonical CAS object, saving storage.
<br><br>
The primary motivating use-case for this project is the dependency scanner
that's powering "implicitly-discovered, explicitly-built" Clang modules.
There are real-world situations where even coarse de-duplication on the
block level could halve the size of the scanning module cache.
</p>
<p><b>Expected result:</b>
There's a way to configure the LLVM bitstream writer/reader to use CAS as
the backing storage.
</p>
<p><b>Skills:</b>
Intermediate knowledge of C++, some familiarity with data serialization, self-motivation.
</p>
<p><b>Project size:</b> Medium or large</p>
<p><b>Confirmed Mentors:</b>
<a href="https://github.com/jansvoboda11/">Jan Svoboda</a>,
<a href="https://github.com/cachemeifyoucan/">Steven Wu</a></p>
<p><b>Discourse:</b>
<a href="https://discourse.llvm.org/t/llvm-bitstream-integration-with-cas-content-addressable-storage/76757">URL</a>
</p>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="three_way_comparison">Add 3-way comparison intrinsics</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
<a href="https://en.wikipedia.org/wiki/Three-way_comparison">3-way comparisons</a>
return the values -1, 0 or 1 depending on whether the values compare lower,
equal or greater. They are exposed in C++ via the spaceship operator
(operator<=>) and in Rust via the PartialOrd and Ord traits.
Currently, such comparisons produce sub-optimal codegen and optimization
results in some cases.
<br/><br/>
The goal of this project is to resolve these optimization issues by
implementing new 3-way comparison intrinsics, as described in
<a href="https://discourse.llvm.org/t/rfc-add-3-way-comparison-intrinsics/76685">[RFC] Add 3-way comparison intrinsics</a>.
The implementation steps are broadly:
<ol>
<li>Add the intrinsics to LLVM IR.</li>
<li>Implement legalization/expansion support in SelectionDAG and
GlobalISel.</li>
<li>Implement optimization support in ConstantFolding, InstSimplify,
InstCombine, CorrelatedValuePropagation, IndVarSimplify,
ConstraintElimination, IPSCCP, and other relevant transforms.</li>
<li> Make use of the intrinsics via InstCombine canonicalization or
direct emission in clang/rustc.</li>
</ol>
Adding new target-independent intrinsics is a good way of becoming familiar with a broad slice of LLVM!
</p>
<p><b>Expected result:</b>
Support for the intrinsics in the backend and the most important
optimization passes. Ideally full integration starting at the frontend.
</p>
<p><b>Skills:</b> Intermediate knowledge of C++ </p>
<p><b>Project size:</b> Medium or large</p>
<p><b>Difficulty:</b> Medium</p>
<p><b>Confirmed Mentors:</b>
<a href="https://github.com/nikic">Nikita Popov</a>,
<a href="https://github.com/dc03">Dhruv Chawla</a></p>
<p><b>Discourse:</b>
<a href="https://discourse.llvm.org/t/llvm-add-3-way-comparison-intrinsics/76807">URL</a>
</p>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="llvm_www">Improve the LLVM.org Website Look and Feel</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
The llvm.org website serves as the central hub for information about the
LLVM project, encompassing project details, current events, and relevant
resources. Over time, the website has evolved organically, prompting the
need for a redesign to enhance its modernity, structure, and ease of
maintenance.
<br/><br/>
The goal of this project is to create a contemporary and coherent static
website that reflects the essence of LLVM.org. This redesign aims to improve
navigation, taxonomy, content discoverability, mobile device support,
accessibility, and overall usability. Given
the critical role of the website in the community, efforts will be made to
engage with community members, seeking consensus on the proposed changes.
</p>
<p><b>Expected result:</b>
A modern, coherent-looking website that attracts new prospect users and
empowers the existing community with better navigation, taxonomy, content
discoverability, and overall usability. Since the website is a critical
infrastructure and most of the community will have an opinion this project
should try to engage with the community building community consensus on the
steps being taken. Suggested approach:
<ul>
<li>Conduct a comprehensive content audit of the existing website.</li>
<li>Select appropriate technologies, preferably static site generators
like Hugo or Jekyll.</li>
<li>Advocate for a separation of data and visualization, utilizing formats
such as YAML and Markdown to facilitate content management without
direct HTML coding.</li>
<li>Present three design mockups for the new website, fostering open
discussions and allowing time for alternative proposals from interested
parties.</li>
<li>Implement the chosen design, incorporating valuable feedback from the
community.</li>
<li>Collaborate with content creators to integrate or update content as
needed.</li>
</ul>
The successful candidate should commit to regular participation in weekly
meetings, deliver presentations, and contribute blog posts as requested.
Additionally, they should demonstrate the ability to navigate the community
process with patience and understanding.
</p>
<p><b>Skills:</b>
Knowledge in the area of web development with static site generators.
Knowledge in html, css, bootstrap, and markdown. Patience and self-motivation.
</p>
<p><b>Difficulty:</b> Hard</p>
<p><b>Project size:</b> Large</p>
<p><b>Confirmed Mentors:</b>
<a href=https://github.com/tlattner>Tanya Lattner</a>,
<a href=https://github.com/vgvassilev>Vassil Vassilev</a>
</p>
<p><b>Discourse:</b>
<a href="https://discourse.llvm.org/t/improve-the-llvm-org-website-look-and-feel/76864">URL</a>
</p>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="clang-repl-out-of-process">Out-of-process execution for clang-repl</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
The Clang compiler is part of the LLVM compiler infrastructure and supports
various languages such as C, C++, ObjC and ObjC++. The design of LLVM and
Clang enables them to be used as libraries, and has led to the creation of
an entire compiler-assisted ecosystem of tools. The relatively friendly
codebase of Clang and advancements in the JIT infrastructure in LLVM further
enable research into different methods for processing C++ by blurring the
boundary between compile time and runtime. Challenges include incremental
compilation and fitting compile/link time optimizations into a more dynamic
environment.
<br /> <br />
Incremental compilation pipelines process code chunk-by-chunk by building an
ever-growing translation unit. Code is then lowered into the LLVM IR and
subsequently run by the LLVM JIT. Such a pipeline allows creation of
efficient interpreters. The interpreter enables interactive exploration and
makes the C++ language more user friendly. Clang-Repl is one example.
<br /> <br />
Clang-Repl uses the Orcv2 JIT infrastructure within the same process. That
design is efficient and easy to implement however it suffers from two
significant drawbacks. First, it cannot be used in devices which do not have
sufficient resources to host the entire infrastructure, such as the arduino
due (see this
<a href="https://compiler-research.org/meetings/#caas_10Mar2022">talk</a>
for more details). Second, crashes in user codes mean that the entire
process crashes, hindering overall reliability and ease of use.
<br /> <br />
This project aims to move Clang-Repl to an out-of-process execution model
in order to address both of these issues.
</p>
<p><b>Expected result:</b>
Implement an out-of-process execution of statements with Clang-Repl;
Demonstrate that Clang-Repl can support some of the ez-clang use-cases;
Research into approaches to restart/continue the session upon crash;
As a stretch goal design a versatile reliability approach for crash recovery;
</p>
<p><b>Skills:</b>
Intermediate knowledge of C++, Understanding of LLVM and the LLVM JIT in particular
</p>
<p><b>Project size:</b>Either medium or large.</p>
<p><b>Difficulty:</b> Medium</p>
<p><b>Confirmed Mentor:</b>
<a href=https://github.com/vgvassilev>Vassil Vassilev</a>,
<a href=https://github.com/weliveindetail>Stefan Gränitz</a>,
</p>
<p><b>Discourse:</b> <a href="https://discourse.llvm.org/t/clang-out-of-process-execution-for-clang-repl/68225">URL</a>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="clang-plugins-windows">Support clang plugins on Windows</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b>
The Clang compiler is part of the LLVM compiler infrastructure and supports
various languages such as C, C++, ObjC and ObjC++. The design of LLVM and
Clang allows the compiler to be extended with plugins[1]. A plugin makes it
possible to run extra user defined actions during a compilation. Plugins
are supported on unix and darwin but not on windows due to some specifics of
the windows platform.
<br /> <br />
This project would expose the participant to a broad cross section of the LLVM codebase. It involves exploring the API surface, classifying the interfaces as being public or private, and annotating that information to the API declarations. It would also expose the participant to details and differences of different platforms as this work is cross-platform (Windows, Linux, Darwin, BSD, etc). The resulting changes would improve LLVM on Linux and Windows while enabling new functionality on Windows.
</p>
<p><b>Expected result:</b>
This project aims to allow make clang -fplugin=windows/plugin.dll work. The
implementation approach should extend the working prototype [3] and extend
the annotation tool [4]. The successful candidate should be prepared to
attend a weekly meeting, make presentations and prepare blog posts upon
request.
</p>
<p><i>Further reading</i><br />
[1] https://clang.llvm.org/docs/ClangPlugins.html
<br />
[2] https://discourse.llvm.org/t/clang-plugins-on-windows
<br />
[3] https://github.com/llvm/llvm-project/pull/67502
<br />
[4] https://github.com/compnerd/ids
</p>
<p><b>Skills:</b>
Intermediate knowledge of C++, Experience with Windows and its compilation
and linking model.
</p>
<p><b>Project size:</b>Either medium or large.</p>
<p><b>Difficulty:</b> Medium</p>
<p><b>Confirmed Mentor:</b>
<a href=https://github.com/vgvassilev>Vassil Vassilev</a>,
<a href=https://github.com/compnerd>Saleem Abdulrasool</a>
</p>
<p><b>Discourse:</b> <a href="https://discourse.llvm.org/t/support-clang-plugins-on-windows/76408">URL</a>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="clang-on-demand-parsing">On Demand Parsing in Clang</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description of the project:</b> Clang, like any C++ compiler, parses a
sequence of characters as they appear, linearly. The linear character
sequence is then turned into tokens and AST before lowering to machine
code. In many cases the end-user code uses a small portion of the C++
entities from the entire translation unit but the user still pays the price
for compiling all of the redundancies.
<br /> <br />
This project proposes to process the heavy compiling C++ entities upon using
them rather than eagerly. This approach is already adopted in Clang’s
CodeGen where it allows Clang to produce code only for what is being
used. On demand compilation is expected to significantly reduce the
compilation peak memory and improve the compile time for translation units
which sparsely use their contents. In addition, that would have a
significant impact on interactive C++ where header inclusion essentially
becomes a no-op and entities will be only parsed on demand.
<br /> <br />
The Cling interpreter implements a very naive but efficient
cross-translation unit lazy compilation optimization which scales across
hundreds of libraries in the field of high-energy physics.
<br /> <br />
<pre>
// A.h
#include <string>
#include <vector>
template <class T, class U = int> struct AStruct {
void doIt() { /*...*/ }
const char* data;
// ...
};
template<class T, class U = AStruct<T>>
inline void freeFunction() { /* ... */ }
inline void doit(unsigned N = 1) { /* ... */ }
// Main.cpp
#include "A.h"
int main() {
doit();
return 0;
}
</pre>
<br /> <br />
This pathological example expands to 37253 lines of code to process. Cling
builds an index (it calls it an autoloading map) where it contains only
forward declarations of these C++ entities. Their size is 3000 lines of
code. The index looks like:
<pre>
// A.h.index
namespace std{inline namespace __1{template <class _Tp, class _Allocator> class __attribute__((annotate("$clingAutoload$vector"))) __attribute__((annotate("$clingAutoload$A.h"))) __vector_base;
}}
...
template <class T, class U = int> struct __attribute__((annotate("$clingAutoload$A.h"))) AStruct;
</pre>
<br /> <br />
Upon requiring the complete type of an entity, Cling includes the relevant
header file to get it. There are several trivial workarounds to deal with
default arguments and default template arguments as they now appear on the
forward declaration and then the definition. You can read more in [1].
<br /> <br />
Although the implementation could not be called a reference implementation,
it shows that the Parser and the Preprocessor of Clang are relatively
stateless and can be used to process character sequences which are not
linear in their nature. In particular namespace-scope definitions are
relatively easy to handle and it is not very difficult to return to
namespace-scope when we lazily parse something. For other contexts such as
local classes we will have lost some essential information such as name
lookup tables for local entities. However, these cases are probably not very
interesting as the lazy parsing granularity is probably worth doing only for
top-level entities.
<br /> <br />
Such implementation can help with already existing issues in the standard
such as CWG2335, under which the delayed portions of classes get parsed
immediately when they're first needed, if that first usage precedes the end
of the class. That should give good motivation to upstream all the
operations needed to return to an enclosing scope and parse something.
<br /> <br />
<b>Implementation approach</b>: Upon seeing a tag definition during parsing
we could create a forward declaration, record the token sequence and mark it
as a lazy definition. Later upon complete type request, we could re-position
the parser to parse the definition body. We already skip some of the
template specializations in a similar way [2, 3].
<br /> <br />
Another approach is every lazy parsed entity to record its token stream and
change the Toks stored on LateParsedDeclarations to optionally refer to a
subsequence of the externally-stored token sequence instead of storing its
own sequence (or maybe change CachedTokens so it can do that
transparently). One of the challenges would be that we currently modify the
cached tokens list to append an "eof" token, but it should be possible to
handle that in a different way.
<br /> <br />
In some cases, a class definition can affect its surrounding context in a
few ways you'll need to be careful about here:
<br /> <br />
1) `struct X` appearing inside the class can introduce the name `X` into the
enclosing context.
<br /> <br />
2) `static inline` declarations can introduce global variables with
non-constant initializers that may have arbitrary side-effects.
<br /> <br />
For point (2), there's a more general problem: parsing any expression can
trigger a template instantiation of a class template that has a static data
member with an initializer that has side-effects. Unlike the above two
cases, I don't think there's any way we can correctly detect and handle such
cases by some simple analysis of the token stream; actual semantic analysis
is required to detect such cases. But perhaps if they happen only in code
that is itself unused, it wouldn't be terrible for Clang to have a language
mode that doesn't guarantee that such instantiations actually happen.
<br /> <br />
Alternative and more efficient implementation could be to make the lookup
tables range based but we do not have even a prototype proving this could be
a feasible approach.
</p>
<p><b>Expected result:</b>
<ul>
<li>Design and implementation of on-demand compilation for non-templated functions</li>
<li>Support non-templated structs and classes</li>
<li>Run performance benchmarks on relevant codebases and prepare report</li>
<li>Prepare a community RFC document</li>
<li>[Stretch goal] Support templates</li>
</ul>
The successful candidate should commit to regular participation in weekly
meetings, deliver presentations, and contribute blog posts as
requested. Additionally, they should demonstrate the ability to navigate the
community process with patience and understanding.
</p>
<p><i>Further reading</i><br/>
[1] https://github.com/root-project/root/blob/master/README/README.CXXMODULES.md#header-parsing-in-root
<br />
[2] https://github.com/llvm/llvm-project/commit/b9fa99649bc99
<br />
[3] https://github.com/llvm/llvm-project/commit/0f192e89405ce
</p>
<p><b>Skills:</b>
Knowledge of C++, Deeper understanding of how Clang works,
knowledge of Clang AST and Preprocessor.
</p>
<p><b>Project size:</b>Large</p>
<p><b>Difficulty:</b> Hard</p>
<p><b>Confirmed Mentor:</b>
<a href=https://github.com/vgvassilev>Vassil Vassilev</a>,
<a href=https://github.com/mizvekov>Matheus Izvekov</a>
</p>
<p><b>Discourse:</b> <a href="https://discourse.llvm.org/t/on-demand-parsing-in-clang/76912">URL</a>
</div>
<!-- *********************************************************************** -->
<div class="www_subsubsection">
<a name="rich-disassembler-for-lldb">Rich Disassembler for LLDB</a>
</div>
<!-- *********************************************************************** -->
<div class="www_text">
<p><b>Description</b></p>
<p>Use the variable location information from the debug info to annotate LLDB’s disassembler (and `register read`) output with the location and lifetime of source variables. The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this. In a terminal, LLDB should render the annotations as text.</p>
<p><b>Expected outcomes</b></p>
For example, we could augment the disassembly for the following function
<pre>
frame #0: 0x0000000100000f80 a.out`main(argc=1, argv=0x00007ff7bfeff1d8) at demo.c:4:10 [opt]
1 void puts(const char*);
2 int main(int argc, char **argv) {
3 for (int i = 0; i < argc; ++i)
→ 4 puts(argv[i]);
5 return 0;
6 }
(lldb) disassemble
a.out`main:
...
0x100000f71 <+17>: movl %edi, %r14d
0x100000f74 <+20>: xorl %r15d, %r15d
0x100000f77 <+23>: nopw (%rax,%rax)
→ 0x100000f80 <+32>: movq (%rbx,%r15,8), %rdi
0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts
0x100000f89 <+41>: incq %r15
0x100000f8c <+44>: cmpq %r15, %r14
0x100000f8f <+47>: jne 0x100000f80 ; <+32> at demo.c:4:10
0x100000f91 <+49>: addq $0x8, %rsp
0x100000f95 <+53>: popq %rbx
...
</pre>
<p>using the debug information that LLDB also has access to (observe how the source variable i is in r15 from [0x100000f77+slide))</p>
<pre>
$ dwarfdump demo.dSYM --name i
demo.dSYM/Contents/Resources/DWARF/demo: file format Mach-O 64-bit x86-64
0x00000076: DW_TAG_variable
DW_AT_location (0x00000098:
[0x0000000100000f60, 0x0000000100000f77): DW_OP_consts +0, DW_OP_stack_value
[0x0000000100000f77, 0x0000000100000f91): DW_OP_reg15 R15)
DW_AT_name ("i")
DW_AT_decl_file ("/tmp/t.c")
DW_AT_decl_line (3)
DW_AT_type (0x000000b2 "int")
</pre>
to produce output like this, where we annotate when a variable is live and what its location is:
<pre>
(lldb) disassemble
a.out`main:
... ; i=0
0x100000f74 <+20>: xorl %r15d, %r15d ; i=r15
0x100000f77 <+23>: nopw (%rax,%rax) ; |
→ 0x100000f80 <+32>: movq (%rbx,%r15,8), %rdi ; |
0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts ; |
0x100000f89 <+41>: incq %r15 ; |
0x100000f8c <+44>: cmpq %r15, %r14 ; |
0x100000f8f <+47>: jne 0x100000f80 ; <+32> at t.c:4:10 ; |
0x100000f91 <+49>: addq $0x8, %rsp ; i=undef
0x100000f95 <+53>: popq %rbx
</pre>
<p>The goal would be to produce output like this for a subset of unambiguous cases, for example, variables that are constant or fully in registers.</p>