dibyendumajumdar / dmr_c Goto Github PK
View Code? Open in Web Editor NEWdmr_C is a C parser and JIT compiler with LLVM, Eclipse OMR and NanoJIT backends
License: Other
dmr_C is a C parser and JIT compiler with LLVM, Eclipse OMR and NanoJIT backends
License: Other
To support compiling buffers the initialize step must be performed even if no files are present.
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.
In some places sparse code uses long type. This should be changed to int or long long type as long type is not portable
The showsymbols tool is generating invalid xml as there is no root tag. Also the xml header tag is missing
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.
The mapping of type modifiers to strings is out of sync with the modifier definitions.
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.
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.
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:
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().
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.
[ 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?
The sparse-llvm backend does not handle initialization of local static or global static variables except for very simple global statics such as strings.
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.
In this option the linearizer will be excluded, as will any JIT backends.
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.
Details and discussion of this issue:
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.
Details here:
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.
If you have a pointer to function then following works:
f()
But this doesn't:
(*f)()
The generated linearized output is wrong.
More specifically:
Purpose is twofold:
a) Create a small JIT
b) Learn assembly programming
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
The API currently supports compiling source code in files. We should also have the ability to compile source code in a memory buffer.
We need to allow for the condition value to be a basic type and not a SYM_NODE.
#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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.