Summary:
This revision removes all of the functionality related to successor operands on the core Operation class. This greatly simplifies a lot of handling of operands, as well as successors. For example, DialectConversion no longer needs a special "matchAndRewrite" for branching terminator operations.(Note, the existing method was also broken for operations with variadic successors!!)

This also enables terminator operations to define their own relationships with successor arguments, instead of the hardcoded "pass-through" behavior that exists today.

Differential Revision: https://reviews.llvm.org/D75318

The existing API for successor operands on operations is in the process of being removed. This revision simplifies a later one that completely removes the existing API.

Differential Revision: https://reviews.llvm.org/D75316

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.

This was left over debugging.

Summary: These were temporary methods used to simplify the transition.

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D72548

ValuePtr was a temporary typedef during the transition to a value-typed Value.

PiperOrigin-RevId: 286945714

PiperOrigin-RevId: 286906740

NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.

This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ

This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.

PiperOrigin-RevId: 286844725

Aside from being cleaner, this also makes the codebase more consistent.

PiperOrigin-RevId: 286206974

PiperOrigin-RevId: 281656603

This moves the different canonicalizations of regions into one place and invokes them in the fixed-point iteration of the canonicalizer.

PiperOrigin-RevId: 281617072

This will allow clients to implement a different collection strategy on these
values, including collecting each uses within the region for example.

PiperOrigin-RevId: 267803978

This is a convenient utility around the existing `getUsedValuesDefinedAbove()`
that take two regions.

PiperOrigin-RevId: 266686854

There are currently several different terms used to refer to a parent IR unit in 'get' methods: getParent/getEnclosing/getContaining. This cl standardizes all of these methods to use 'getParent*'.

PiperOrigin-RevId: 262680287

Arguably, this function is only useful for transformations and should not
pollute the main IR.  Also make sure it accepts a the resulting container
by-reference instead of returning it.

PiperOrigin-RevId: 253622981

This converts entire loops into threads/blocks.  No check on the size of the
block or grid, or on the validity of parallelization is performed, it is under
the responsibility of the caller to strip-mine the loops and to perform the
dependence analysis before calling the conversion.

PiperOrigin-RevId: 253189268

    This is in preparation for making it also support/be a parent class of MemRefType. MemRefs have similar shape/rank/element semantics and it would be useful to be able to use these same utilities for them.

    This CL should not change any semantics and only change variables, types, string literals, and comments. In follow-up CLs I will prepare all callers to handle MemRef types or remove their dependence on ShapedType.

    Discussion/Rationale in https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/cHLoyfGu8y8

--

PiperOrigin-RevId: 248476449

    This adds some additional core types and utilities, notably the constraint analysis graph (CAG) structures, associated metadata and configuration policy object base class.

    The CAG is not particularly memory efficient as it stands now. I had started some work to turn it into a form that could be better managed by a bump pointer allocator but abandoned that for now in favor of having something that does semantically what I was going for as a starting point.

--

PiperOrigin-RevId: 248413133

    These are only required in .h files to disambiguate between C and C++ header files.

--

PiperOrigin-RevId: 248219135

    Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`.
    Even if an op has only one variadic operand/result, it is not necessarily the
    very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be
    able to represent such cases.

    In order to deduce the operand/result value range for each variadic operand,
    currently we only support variadic operands/results all of the same size.
    So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are
    introduced.

--

PiperOrigin-RevId: 245310628

    Now, op attribute names don't have '.' in their names so the special handling for it
    can be removed. Attributes for functions still have dialect prefix with '.' as separator but TableGen does not deal with functions.

    TESTED with existing unit tests

--

PiperOrigin-RevId: 243287462

Previously Value was a pair of name & Type, but for operands/result a TypeConstraint rather then a Type is specified. Update C++ side to match declarative side.

PiperOrigin-RevId: 238984799

Change the TensorFlow attribute prefix from "tf$" to "tf." to match the specification of dialect attributes. This also fixes tblgen generation of dialect attributes that used the sugared name "tf$attr" as c++ identifiers.

PiperOrigin-RevId: 236924392

We specify op operands and results in TableGen op definition using the same syntax.
They should be modelled similarly in TableGen driver wrapper classes.

PiperOrigin-RevId: 234153332

This is another step towards hiding raw TableGen API calls.

PiperOrigin-RevId: 231580827

PiperOrigin-RevId: 230923050