Difference between revisions of "LDC project ideas"

From D Wiki
Jump to: navigation, search
(Add link to LLVM profiling instrumentation page)
(Maintain an LDC package)
 
(4 intermediate revisions by 3 users not shown)
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.
  
; Windows 32bit [Intermediate]
+
; Compile D code as CUDA kernel [Expert] (See [http://dconf.org/2017/talks/wilson.html DCompute])
: LDC has growing support for Win64. LLVM 3.7 adds structured exception handling for Windows 32  bit. The exception handling infrastructure (code generation and druntime support) has to be adapted to this new approach and streamlined with the 64bit version. In addition, druntime and phobos support must be verified and possible extended.
 
 
 
; Compile D code as CUDA kernel [Expert]
 
 
: 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 28: Line 25:
 
== Adding new features ==
 
== Adding new features ==
  
; Add support for the [[LLVM profiling instrumentation]] [Intermediate]
+
; Add support for the [[LDC LLVM profiling instrumentation|LLVM profiling instrumentation]] [Intermediate]
: LLVM offers support for profiling and coverage instrumentation. Add code to support these instrumentations. Write D tools to analyze the generated data.
+
: 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]
 
; Check other tools from LLVM ecosystem for integration/interaction with LDC [Intermediate/Expert]
Line 55: 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]
Line 61: Line 58:
 
== Maintain an LDC package ==
 
== 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)
+
* Currently, LDC is included into FreeBSD ports tree and it is maintained by Alonso Cárdenas Márquez (acm@FreeBSD.org) (http://www.freshports.org/lang/ldc)
 
* Create and maintain a Solaris/OpenIndiana IPS port.
 
* Create and maintain a Solaris/OpenIndiana IPS port.
  
 
[[Category:LDC]]
 
[[Category:LDC]]

Latest revision as of 18:41, 16 July 2017

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

  • Currently, LDC is included into FreeBSD ports tree and it is maintained by Alonso Cárdenas Márquez (acm@FreeBSD.org) (http://www.freshports.org/lang/ldc)
  • Create and maintain a Solaris/OpenIndiana IPS port.