I've noticed that LLVM provides several built-in Analysis and Transform Passes. Can I run these built-in passes (e.g., -da for dependency analysis) directly with clang instead of opt?
Yes, LLVM provides a mechanism to automatically register pass plugins within clang. You may need to read here
However the above reference deals with legacy pass manager. LLVM uses the new pass manager by default for the optimization pipeline.
LLVM’s New Pass Manager
Using the New Pass Manager
Related
I want to generate code from dart files especially from dart packages at runtime.
I have been using build_runner as a dev_dependency to parse and generate code, which is really awesome! But the problem that I don't know how to use it as a normal dependency so I can use in my application.
Also I found that build_runner uses analyzer as a core, but didn't find good documentation about them.
So, how can I use build_runner as a normal dependency to parse and generate code at runtime?
Thanks in advance.
You can perform actions that the build_runner run CLI command does with the run function exposed programatically.
For lower-level access to build logic that may be more suited to programatic usage, the APIs provided by package:build may be more useful. Alternatively, the actual code generation packages may expose their own APIs for code generation.
In Java we can use annotations to generate code automatically at compile time, this feature is amazing for reducing bioler plate code. Many great libraries such as Retrofit, Room and AutoValue use it.
Does Dart have similar features?
Dart indeed allows for code-generation using the same principles.
An examples would be json_serializable, which generates fromJSON constructor and toJSON methods for classes inside yourfile.g.dart
In general, dart team provided an awesome tooling for code generation. If you want to create your own code generator, feel free to take a look at source_gen or simply build
I would like to define my objects in a JSON file, and then instantiate them using Typhoon. Is this currently possible with Typhoon? I've downloaded the code from github, and looked through the code and docs, but I don't see a way.
Thanks in advance!
Since Typhoon 2.0 we only support the native format (recommended) along with auto-wiring macros. The main benefits are:
IDE refactoring and code-completion works without any additional plugins
No "magic strings" when wiring by reference.
Components can be resolved using the assembly interface. Since version 2.0 this includes supplying runtime arguments along with static dependencies.
In version 1.x, we supported XML along with the above styles, however it was not at all a popular feature. The main (valid) criticisms were that XML doesn't support the above benefits of the native style. This along with there being some overheads in maintenance lead us to decide to discontinue support in version 2.0.
There was one benefit - the ability to define assemblies at runtime. The closest thing that we have at the moment is Typhoon Config, which allows defining configurations in a text file.
Proceeding with JSON:
It would be quite simple to define a JSON parser.
Create a similar class to v1.8.2's XML parser.
Register the components from the parser. Either manually or by creating a TyphoonComponentFactory sub-class.
Unless you have a strong reason for using JSON, we recommend the native style.
I'm trying to work on transform passes in LLVM aimed at every OpenMP parallel section which are mentioned using 'omp pragmas'.
I'm thinking something like: Module level, Function level and basic block level, can I write any passes at a parallel loop level. If yes, any directions on this would be really helpful.
Cheers.
There is an open source Implementation of OpenMP support in clang in clang-omp.github.com. It uses Intel's libiomp5 which can be downloaded from openmp.llvm.org
Is this statement true:
com.sun.xml.internal package is an internal package as the name suggestes.
Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice
One of my colleagues used one of the classes in his code, which caused javac task in Ant fail to compile our project as the compiler couldn't find the class. Answer from Sun/Oracle says that this is expected behavior of the compiler as user shouldn't use the package.
Question is why the classes in the package made public in the first place?
Thanks,
Sarah
Sun classes in the JDK are prefixed sun.* and are not part of the public supported interface so should be used with care. From the Sun FAQ:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java., javax.,
org.* and sun.. All but the sun.
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun., that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.
packages are not 100% Pure Java. In
other words:
The java., javax. and org.* packages
documented in the Java 2 Platform
Standard Edition API Specification
make up the official, supported,
public interface.
If a Java program directly calls only
API in these packages, it will operate
on all Java-compatible platforms,
regardless of the underlying OS
platform.
The sun.* packages are not part of the
supported, public interface.
A Java program that directly calls
into sun.* packages is not guaranteed
to work on all Java-compatible
platforms. In fact, such a program is
not guaranteed to work even in future
versions on the same platform.
It's because Java visibility modifiers (especially at the type level, where there are only two options) don't currently have the granularity to achieve the sort of visibility you're hinting at. I don't know the specifics of the internal class or classes you're using, but basically making the classes private would have made them unfit for their intended purpose, so the only other choice was public.
Sadly JAXB (bundled with Java6) seems to rely on a non-public class "com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper" to allow you to specify namespace prefixes when marshalling to xml.
You have to really go out of your way to get this compiling with ant:
http://pragmaticintegration.blogspot.com/
Summary:
Option 1.
Add jre libs as bootclasspathref
Add property: includeJavaRuntime="yes"
Option 2.
Use JAXB-RI libs - change property to "com.sun.xml.bind.marshaller.NamespacePrefixMapper"
Also mentioned here:
Define Spring JAXB namespaces without using NamespacePrefixMapper