The freecompilercamp.org has a very good tutorial about defining OpenMP Directives.
However, apart from this I was unable to find any good resource on how to add new directives,
clauses etc for OpenMP in llvm.
Moreover, I am interested in knowing more about what OPENMP_DIRECTIVE_EXT is and how to declare a new one? Any guide about this or how the User defined Reduction is implemented would be helpful. Even a link to the patchset or pull request that added this functionality would be helpful.
Thank you!
Citing the openMP spec -
Compilers can therefore ignore OpenMP directives and conditionally compiled code if support of the OpenMP API is not provided or enabled. A compliant implementation must provide an option or interface that ensures that underlying support of all OpenMP directives and OpenMP conditional compilation mechanisms is enabled. In the remainder of this document, the phrase OpenMP compilation is used to mean a compilation with these OpenMP features enabled.
In other words, the directives are a programming tool to allow compilers to compile code under it if an existing implementation for such a directive exists and otherwise falls back to compiling the code as normal for a cpu. I also found this IBM page which explains the pragmas a bit further.
I didn't really find any other tutorial than the one you mention. You should probably look at the clang tutorials in that site. I think the OpenMP directives are implemented as a clang frontend parser. You need to parse the structured code inside the directive and add a new AST node. This will be compiled to LLVM IR and passed to LLVM where you can do more transformations to the IR.
Related
https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.
Can Intel's icc compiler produce Lint results like gcc does with 'make lint' command ? I checked but could not found anything, is there any other alternative to do so?
A make lint command sounds like some particular makefile. Checking the default rules for GNU make does not show one (though you could have this with a file named lint.c).
gcc supports several compiler warnings, but does not do what lint does: combined analysis across multiple files. icc provides similar compiler warnings, and recognizes enough of gcc's warnings to allow it to be used interchangeably in some makefiles. However, strict warnings do differ. In both cases, those are considered part of static analysis. Some tools go further (clang, for instance provides extra compiler warnings with its --analyze option, though this too falls short of the multiple-file feature of lint). I use these compilers, have configure script options to check for and turn them on. But at the moment, the only tool which I am using that provides multiple-file analysis is Coverity. (Some people find splint useful; I have tried it more than once and not agreed).
Here are a few links which are useful for further reading:
Static Analysis Overview, Intel C++ Compiler XE 13.1 User and Reference Guides (which by the way does not mention lint)
Parallel Lint by Andrey Karpov, which includes notes on static analysis in the Intel compiler
lint still useful?, newsgroup thread listing possibilities
I am using the 2011 Q3 ARM GCC compiler with an ARM M0 platform. On my current application, if I do not use optimizations (compiling with -O0), my code is too large and doesn't fit. If I use any optimization (-O1, -O2, -O3, -Os), the SWITCH CASE statements do not work. I have validated the code inside this block is not getting executed as simple GPIO toggling operations are not coming through.
I read somewhere that any optimization from -O1 and above will have issues with goto code. However, I can't find the solution to this problem anywhere.
I also tried using the latest GCC ARM compiler, but my tools are not compatible with this release.
Any help on this matter is appreciated!
Try splitting your source code like so: the code that you don't want to optimize (eg. accesses to the memory mapped regions like GPIO) and the rest of it.
After you compile each source file with a different optimization level, you will get a working version with the "fragile" code.
Then, when you will debug the code, you will work with an object (.o) file and compile the rest.
It is needed to gather the necessary information about the translation unit using the plugin for GCC and to modify AST on its base.
I've already understood how to gather information. But I haven't understand yet how to modify AST before it's passed into CRT. Very little information is available on this subject.
Tell me plese what should I read on this subject? Share thoughts, links.
Thank's.
P.S.
I've already read everything on these links:
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version
http://developer.apple.com/library/mac/#documentation/DeveloperTools/gcc-4.2.1/gccint/index.html#Top
The GCC test suite contains a basic examples of such modifications. See http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/plugin/finish_unit_plugin.c and start_unit_plugin.c shows how to create a var. Unfortunately for more serious modifications the GCC source code are probably your best bet.
Are you tied to GCC for this endeavor? The ROSE compiler is built specifically for performing source-level modification, then handing the resulting code off to a backend compiler.
We have Oracle 11 running on HP-UX 11.31 and gcc 4.4.3. It seems that there is no way to link to occi, because it was built with aCC. Is there any workaround for this?
I had the silly idea that I could somehow build a library that basically proxied the connection - build the library with aCC in some way that could be linked to by gcc. Is this possible?
No, there isn't a way around that.
Different C compilers have interchangeable code using a standard ABI. You can mix and match their object code more or less with impunity.
However, different C++ compilers have a variety of different conventions that mean that their object code is not compatible. These relate to class layout (especially in multiple inheritance hierarchies and the dreaded 'diamond-of-death'), but also in name mangling conventions and exception handling. The name mangling schemes are deliberately made different so that you cannot accidentally link objects from one compiler with another.
Generally, if libraries are built using a C++ compiler, you have to link your code using the same - or at least a compatible - C++ compiler. And that almost invariably means a compiler from the same family. For example, you might be able to use G++ 4.5.0 even if the code was built with G++ 4.4.2. However, you won't be able to mix aCC with G++.