In the previous state, we were relying on forcing the linker to include
all libraries in the final binary and the global initializer to self-register
every piece of the system. This change help moving away from this model, and
allow users to compose pieces more freely. The current change is only "fixing"
the dialect registration and avoiding relying on "whole link" for the passes.
The translation is still relying on the global registry, and some refactoring
is needed to make this all more convenient.
Differential Revision: https://reviews.llvm.org/D74461
Swap the allowed nesting of sum and diff expressions: now a diff expression can
contain a sum expression, but only on the left hand side. A difference of two
expressions sum must be canonicalized by grouping their constant terms in a
single expression. This change of sturcture became possible thanks to the
introduction of the "direct" super-kind. It is necessary to enable support of
sum expressions on the left hand side of the stripe expression.
SDBM expressions are now grouped into the following structure
- expression
- varying
- direct
- sum <- (term, constant)
- term
- symbol
- dimension
- stripe <- (term, constant)
- negation <- (direct)
- difference <- (direct, term)
- constant
The notation <- (...) denotes the types of subexpressions a compound
expression can combine.
PiperOrigin-RevId: 269337222
The initial implementation of SDBM mistakenly swapped the order of variables in
the inequalities induced by a stripe equality: y = x # B actually implies
y - x <= 0 and x - y <= B - 1 rather than x - y <= 0 and y - x <= B - 1 as
implemented. Textual comments in the test files were correct but did not
correspond to the emitted IR. Round-tripping between SDBM and expression lists
was not affected because the wrong order was used in both directions of the
conversion. Use the correct order.
PiperOrigin-RevId: 251252980
MLIRContext does not have to be aware of the SDBM unique data structures
directly. Move the SDBM storage uniquer from MLIRContext to the SDBM dialect
instance. Expressions that previously required a context to be constructed now
require an instance of the dialect in order to access the uniquer. While they
could look up the dialect in the context, it would have introduced a rather
expensive lookup into each construction. Instead, the caller is expected to
obtain the dialect instance and cache it.
--
PiperOrigin-RevId: 249245199
We now have sufficient extensibility in dialects to move attribute components
such as SDBM out of the core IR into a dedicated dialect and make them
optional. Introduce an SDBM dialect and move the code. This is a mostly
non-functional change.
--
PiperOrigin-RevId: 249244802
Jonathan Roelofs