dibyendumajumdar/dmr_c

dmr_C is a C parser and JIT compiler with LLVM, Eclipse OMR and NanoJIT backends

dmr_c's Issues

Check whether the empty file list check in dmrC_sparse_initialize() can be permanently removed

To support compiling buffers the initialize step must be performed even if no files are present.

Review error handling to avoid program termination on error

The sparse implementation simply exits on encountering errors ... but as a library we cannot do that, so we need an alternative method. Perhaps we can supply an error handler that is called - and this can do a long jmp. We can then allow the caller to handle it. Obviously once an error has occurred then the dmr_C instance should not be used anymore.

Avoid using long type

In some places sparse code uses long type. This should be changed to int or long long type as long type is not portable

showsymbols output XML needs a root element

The showsymbols tool is generating invalid xml as there is no root tag. Also the xml header tag is missing

Variables must be initialized before use else compilation may fail

If a local variable is not initialized before use then the linearizer sets this to VOID - this will result in a failure in sparse-llvm.

showsymbols mapping of type modifiers is incorrect

The mapping of type modifiers to strings is out of sync with the modifier definitions.

A conditional branch may be omitted by NanoJIT

It seems that NanoJIT may decide to omit a conditional branch if the code can simply fall through. The branch instructions is returned as NULL in this case causing a crash. We need to detect and avoid trying to add the NULL instruction to the list of jumps to be resolved.

Reinstate type specific ptr list

When I ported Sparse to Windows, I removed all the type specific ptr_list types - and instead used ptr_list directly. However, this makes the code less readable as the list type is not evident, and also creates unnecessary differences when comparing with Sparse. This issue is to restore the type specific ptr_list definitions but do it in a way that I can understand.

The linearizer outputs OP_CAST instead of OP_PTRCAST

Create an X86_64 backend using NanoJIT

Sparse-LLVM attempts to put wrong type on PSEUDO_VAL

Missing liveness information causes stack being over-written

It seems that allocas need to have liveness information added else when NanoJIT's spills registers it may overwrite stack slots.

There are two situations:

1. Phi instructions generate allocas - these should be handled when a jump goes back to a prior block. Any phi related allocas in the target block must be marked live.
2. For allocas arising from local var declarations that were not converted to pseudos, we can add liveness instructions for all the allocas, as we do not have better information at present.

NanoJIT backend fails with assertion error on CBR instruction

It seems that NanoJIT can decide that a branch isn't needed, in which case the NJX_cbr_true() or NJX_cbr_false() returns NULL. Failure occurs in output_op_cbr().

Work out how to avoid global allocator for ptr_list nodes

The Sparse library uses a pointer linked list implementation called ptr_list. The list is maintained as a circular list and there is no defined head or tail - any node can be treated as the head. The library relies upon this feature. The list is represented simply by a pointer to one of the nodes. The problem is that there is no way to associate an allocator with a list, so the ptr_list nodes are managed via a global allocator. Unfortunately the lists created by the parser are not "destroyed" individually - the entire allocator can be destroyed but because this is global, then the issue is that there must not be any active dmr_C instances.

Error Building without a backend

dmr_c/build>$ make

[ 71%] Built target dmr_c
[ 77%] Built target runtests
[ 80%] Building C object CMakeFiles/showsymbols.dir/samples/show-symbols.c.o
/home/guest/Gits/Compiler/dmr_c/samples/show-symbols.c:34:10: fatal error: dmr_c.h: No such file or directory
 #include <dmr_c.h>
          ^~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/showsymbols.dir/build.make:63: CMakeFiles/showsymbols.dir/samples/show-symbols.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:142: CMakeFiles/showsymbols.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

how fix?

Initializers of local / global static variables not fully supported

The sparse-llvm backend does not handle initialization of local static or global static variables except for very simple global statics such as strings.

Unable to handle assignment to a bitfield when optimizations are enabled and the struct has not been initialized

Example code that fails when -O1 option is enabled:

https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/set1/onebit.c

For a discussion of this issue see:

http://marc.info/?l=linux-sparse&m=149074012006676&w=3

Workaround is to disable optimizations by not supplying -O1.

Add a build option that only includes the preprocessor and C parser

In this option the linearizer will be excluded, as will any JIT backends.

Variable argument handling is incorrect

Variable argument handling requires special LLVM instructions to be generated as described in:

http://llvm.org/docs/LangRef.html#int-varargs

However, sparse doesn't output special instructions for va_arg - instead it relies on macros that do not really work.

Array size where the size is computed through the initializer is not handled correctly by sparse-llvm

Details and discussion of this issue:

http://marc.info/?l=linux-sparse&m=149081906729275&w=3

Make the sparse-llvm interface available as a library interface

The goal of dmr_C is to be used as a library, hence we need to expose the LLVM compilation API to users of the library.

All objects and functions with external linkage should also be prefixed with 'dmrC_' to avoid polluting the global namespace.

The llvm backend does not handle assignment of aggregate types

Details here:

http://marc.info/?l=linux-sparse&m=149070429925870&w=3

Change the LLVM api to accept a Module

Allowing the user to create the LLVM module is important to allow the user to add additional stuff to the module. So it is better to accept the Module as a parameter rather than creating it within the API.

(*)() function pointer call syntax is not handled correctly

If you have a pointer to function then following works:

f()

But this doesn't:

(*f)()

The generated linearized output is wrong.

Create new JIT backend using Eclipse OMR technology

More specifically:

https://github.com/dibyendumajumdar/nj

Merge pseudo with size patch by Chris Lee

Create an X86-64 backend using asmjit

Purpose is twofold:

a) Create a small JIT
b) Learn assembly programming

NanoJIT backend fails on AND_BOOL instruction

Turns out the instruction size is set to 1, but NanoJIT results from tests result in int32 value. This problem could be in multiple places

Add the ability to compile a buffer

The API currently supports compiling source code in files. We should also have the ability to compile source code in a memory buffer.

Bug in the conversion of a symbol type in switch condition

We need to allow for the condition value to be a basic type and not a SYM_NODE.

Remove experimental newssa implementation

Linearizer outputs incorrect code if a variable is initialized inside a branch

#An example of this issue is in:

https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/bugs/simplifybug.c

Also see:

http://marc.info/?l=linux-sparse&m=149017414417644&w=3

The workaround is to disable sparse simplifications. In dmr_C this is achieved by making simplification optional - it is triggered only if -O1 option is supplied.

Refactor code to avoid simplification

The sparse simplification phase is error prone and given there is no active compiler experts looking at this it is unlikely to improve. Given Jit backends such as llvm and omr have robust optimizers we don't really need sparse to do it's simplifications

NanoJIT backend: call NJX api to get a reference to function parameters

In JITed function the parameters appear in registers of 64-bit size. So if an int is needed then it needs a conversion from quad to int. This should be done whenever the parameter is needed rather than at the start, as then hopefully there will not be issues related to liveness