Difference between revisions of "LDC project ideas"
m (Win32 has been supported for a while now... ;)) |
m (Mentions DCompute. libconfig already replaced.) |
||
Line 8: | Line 8: | ||
: LDC already supports Solaris and Linux on x86. A code generator for SPARC is part of LLVM core distribution. Adding support for SPARC is therefore only a matter of adding the missing pieces to druntime and phobos. At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to introduce a new ABI class to LDC. | : LDC already supports Solaris and Linux on x86. A code generator for SPARC is part of LLVM core distribution. Adding support for SPARC is therefore only a matter of adding the missing pieces to druntime and phobos. At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to introduce a new ABI class to LDC. | ||
− | ; Compile D code as CUDA kernel [Expert] | + | ; Compile D code as CUDA kernel [Expert] (See [http://dconf.org/2017/talks/wilson.html DCompute]) |
: LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a host compile, a function marked with @kernel requires special care. The function body is not codegened. Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, only the functions marked with @kernel are considered. There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. E.g. a kernel function cannot use dynamic memory or output something using printf(). | : LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a host compile, a function marked with @kernel requires special care. The function body is not codegened. Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, only the functions marked with @kernel are considered. There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. E.g. a kernel function cannot use dynamic memory or output something using printf(). | ||
Line 52: | Line 52: | ||
== Move source code to D == | == Move source code to D == | ||
− | * Create a libconfig clone in D under the LDC license. [Beginner] | + | * Create a libconfig clone in D under the LDC license. [Beginner] [Done] |
* Create a workable binding to the LLVM C++ API. (Note: all available D bindings use the C API which is not usable for LDC.) [Expert] | * Create a workable binding to the LLVM C++ API. (Note: all available D bindings use the C API which is not usable for LDC.) [Expert] | ||
* Translate ldmd2 to D. [Beginner] | * Translate ldmd2 to D. [Beginner] |
Revision as of 13:45, 3 May 2017
Contents
LDC Project ideas
You like LDC and want to contribute? Here is a collection of ideas you can use as a starting point.
Support a new platform
- SPARC (Solaris/Linux) [Beginner]
- LDC already supports Solaris and Linux on x86. A code generator for SPARC is part of LLVM core distribution. Adding support for SPARC is therefore only a matter of adding the missing pieces to druntime and phobos. At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to introduce a new ABI class to LDC.
- Compile D code as CUDA kernel [Expert] (See DCompute)
- LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a host compile, a function marked with @kernel requires special care. The function body is not codegened. Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, only the functions marked with @kernel are considered. There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. E.g. a kernel function cannot use dynamic memory or output something using printf().
- Support for AIX [Expert]
- LLVM generates code for PowerPC CPUs but has no support for AIX. The first step is therefore to output assembler which the AIX assembler can read. This is not too complicated. In addition, the calling conventions has to be checked. The second step (not needed in our case) would be to support the XCOFF binary format. As soon as LLVM can generate code fo AIX, the necessary runtime support needs to be added to druntime and phobos. (I already have some system headers translated.) LDC itself knows about AIX but this support is completely untested.
- Support for SystemZ [Intermediate/Export]
- The LLVM code generators supports SystemZ and LDC can use it as target. Druntime and Phobos support is incomplete.
- Support for *BSD [Beginner - only druntime/Phobos changes]
- LDC runs on FreeBSD. Support for other BSD flavors should be easy to add: OpenBSD, NetBSD, DragonFly BSD. LDC already knows about theses OS but druntime/Phobos miss some declarations.
- Add support for your favourite OS or CPU! [Beginner/Intermediate/Expert]
- Want LDC for Plan9? A compiler for Tilera CPUs? Choose your target and contribute your work!
Adding new features
- Add support for the LLVM profiling instrumentation [Intermediate]
- LLVM offers support for profiling and coverage instrumentation. Add code to support these instrumentations (profiling+PGO is already present). Write D tools to analyze the generated data.
- Check other tools from LLVM ecosystem for integration/interaction with LDC [Intermediate/Expert]
- The LLVM ecosystem provides a lot of useful tools. Some of them might add value to LDC, too.
- * Add D mangling to LLDB
- * Improve sanitizer support in LDC
Improve existing code
- Help to improve the existing non-x86 platforms.
- ARM and PowerPC ports exist but there are still rough edges. Find the rough edges and provide solutions for them!
- Reduce memory consumption and improve performance of LDC [Intermediate/Expert]
- LDC is slow compared to DMD. Use profiling to identify performance and memory allocation hotspots and then propose pull requests to fix these hotspots.
- Add platform specific code [Beginner/Intermediate/Expert]
- Phobos contains some platform-specific optimizations, e.g. std.internal.math.biguintx86. Some of this code should go upstream and be shared between LDC and GDC.
- * std.internal.math.biguintnoasm can be replaced with inline assembler versions on all platforms
- * Digest algorithm can use new specific instructions, e.g. on PowerPC 8 or Octeon MIPS64 CPUs
- * core.cpuid for non-x86 platforms is missing (parse /proc/cpuid on Linux systems)
- Create dsmith
- csmith is a tool which generates random C code. dsmith should over the same for D. Generate random but valid code and run different compilers (LDC, GDC, DMD, SDC, ...) on the code and then compare the results. This is a nice way to discover bugs, because you automatically generate a test case!
Move source code to D
- Create a libconfig clone in D under the LDC license. [Beginner] [Done]
- Create a workable binding to the LLVM C++ API. (Note: all available D bindings use the C API which is not usable for LDC.) [Expert]
- Translate ldmd2 to D. [Beginner]
Maintain an LDC package
- Create and maintain a FreeBSD fresh port. (The old, now deleted port can be used as starting point. See https://svnweb.freebsd.org/ports/head/lang/ldc-devel/?pathrev=325482)
- Create and maintain a Solaris/OpenIndiana IPS port.