RecursiveCoroutines are a facility intended to be used as-drop in
replacement of recursive functions.
They provide the following features.
- They can be written almost as regular recursive functions,
with 4 caveats.
1. A recursive coroutine that returns a type `T`, needs to be declared
to return a `RecursiveCoroutine<T>`.
2. Inside the body of a recursive coroutine, when recursively calling
another recursive coroutine, the recursive call needs to be
prepended by the new keyword `rc_recur`.
3. Inside the body of a recursive coroutine, the `return` statement
needs to be substituted with `rc_return`.
4. When launching a recursive coroutine `A` from a function that is
not a recursive coroutine, `A` needs to be called with the provided
dedicated template wrapper `rc_run`.
The syntax is the following `rc_run(A, arg0, arg1, ...)`.
This is necessary to enable swapping off recursive coroutine and
fall back to regular recursion for debug.
See below for how to do it.
- Unlike regular recursive functions, they don't use the system stack
for recursion. They use a custom heap-allocated stack to manage
recursion. This makes them more robust for implementing recursive
functions that manipulate user-defined input, because they are much
less likely to trigger stack overflow.
- They can be turned off compiling with
`-DDISABLE_RECURSIVE_COROUTINES`, falling back to regular recursion,
for debug purposes.
- They support both direct and indirect recursion, i.e. a recursive
coroutine A can recursively call itself, or it can recursively call
another recursive coroutine B, which in turns recursively calls A.
This is intended to be used by all projects that adopt rev.ng coding
conventions for C++. Each project can create a symbolic link to the
installed .clang-format file, so that IDEs and other dev tools can pick
it up easily while keeping it up-to-date when updating revng.
This enables running the check-revng-conventions script as part of the
build and install process, to generate the .clang-format file for
installation and use from other projects.
This option is enabled with --print-clang-format-config.
This is useful to work around the fact that clang-format configuration
is hard-coded in a file.
Using this option is easier to generate a .clang-format file that can be
dropped in single projects to be picked up by IDE.
After the discovery of new code to be translated, the calls to `newpc`
can be stripped of their variadic arguments (reference to local vars)
in order to let SROA perform more optimization.
`raise_exception_helper` must not return to its caller. Should
`_Unwind_RaiseException` return, something will have gone wrong
with the personality routine; yet this should never happen.
This way we might also save a few bytes and hint the compiler to
avoid storing the callee-saved regs / allocating a new frame.
This assertion was executed in the `runOnModule` method of the GCBI
pass, but it is too strict.
Asserting that Dispatcher != nullptr during the execution of the pass
prevents the pass from successfully running on a Module without a
Dispatcher.
This is unfortunate, because some passes that depend on GCBI in revng-c
actually do that. They do so because they are not really interested in
the Dispatcher at all. They only use GCBI to access information on the
Stack Pointer.
In fact, the check for Dispatcher being != from nullptr is already
performed also in the `dispatcher()` method which is the sane thing to
do. This commit removes the assertion from the `runOnModule` method and
leaves it in the `dispatcher` method.
This allows to run the pass successfully even on a Module without the
Dispatcher, while not changing the contract of this pass (i.e. that when
you call the `dispatcher` method you get a nonnull pointer).
- Use uint32_t
- Define Top as uin32_t max
- Fix copyright notice
- Use using namespace llvm in cpp files
- Change hasSideEffects to isDataFlowSink
- Outline isAddLike
- Add option to ignore certain analysis results
Alessandro Di Federico