<component name="ProjectDictionaryState">
  <dictionary name="sergej.jaskiewicz">
    <words>
      <w>lowerings</w>
      <w>unmuted</w>
    </words>
  </dictionary>

  EXPECT_EQ(non_categorized_count, 428);
}

// Just a counter test to see which ops have duplicate lowerings. This isn't a
// correctness test versus a test to easily ensure the op registry is kept
// in sync.
TEST_F(LegalizationOpConfigTest, CountTypesWhichHaveBothMlirAndTf2xlaFallback) {
  int double_lowering_count = 0;

  DialectRegistry dialect_registry;
  dialect_registry.insert<mlir::TF::TensorFlowDialect>();

// Populates TensorFlow lowering patterns to lower some of the TensorFlow
// operations that can be represented by means of other TensorFlow operations.
// This pattern collection preserves those TensorFlow operations that will later
// be lowered to equivalent operations in CHLO or MHLO. This allows for
// HLO-specific lowerings.
void PopulateTFLoweringBeforeHLOPatterns(MLIRContext *context,

representations (IR) and a code toolkit to perform transformations on that
representation. (In compiler parlance, as you move from higher-level
representations to lower-level representations, these transformations can be
called “lowerings”)

MLIR is highly influenced by [LLVM](https://llvm.org/) and unabashedly reuses
many great ideas from it. It has a flexible type system, and allows
representing, analyzing and transforming graphs combining multiple levels of

import org.jetbrains.kotlin.resolve.BindingContext

@OptIn(KaAnalysisNonPublicApi::class)
fun MutableSet<KtFile>.collectReachableInlineDelegatedPropertyAccessors() {
    if (isEmpty()) return

    // One of the compiler lowerings, namely `PropertyReferenceLowering`,
    // optimizes usages of property references in some cases,
    // and if a containing delegated property accessor is inline,
    // it might need this accessor's bytecode.
    //

even the Swift or Clang type systems (which are built around Swift/Clang
declaration nodes) in the future.

If you want to connect a new low-level compiler, you would create a new dialect
and the lowerings between the TensorFlow Graph dialect and your dialect.
This smooths the path for hardware and compiler makers. You can even target
dialects at different levels in the same model; the higher-level optimizers

  let constructor = "::mlir::tf_test::CreateInitTextFileToImportSavedModelTestPass()";
}

def TestTensorFlowLowerTFPass : Pass<"test-tf-lower-tf", "mlir::func::FuncOp"> {
  let summary = "Test pass for TF->TF lowerings";
  let constructor = "::mlir::tf_test::CreateTestTFLowerTFPass()";

  let options = [
    Option<"default_patterns_", "default-patterns", "bool", /*default=*/"true",
           "Activate the default TF->TF patterns">,

std::unique_ptr<OperationPass<ModuleOp>> createLegalizeTFPass(
    bool legalize_chlo = true,
    std::optional<StringRef> tf2xla_fallback_device_type = std::nullopt,
    bool prefer_tf2xla = false);

/// Adds the TF to TF lowerings and TF to XLA rewrite patterns to the pattern
/// list.
void PopulateLegalizeTfPatterns(MLIRContext* context,
                                RewritePatternSet* patterns);

  // canonicalized to plain HLO constant if statically shaped. Add the
  // canonicalization pattern to pattern list to enable multi-hop lowering.
  chlo::ConstantLikeOp::getCanonicalizationPatterns(patterns, context);

  return ApplyPatterns(op, patterns, legalize_chlo);
}

// Performs the lowering to XLA dialect.
void LegalizeTF::runOnOperation() {
  auto op = getOperation();
  auto op_name = op->getName().getStringRef().str();

    This op is rewritten to generic ops that perform the scale and shift
    and can operate on non-quantized types.

    Currently, TF_DequantizeOp is the only op with a lowering that falls
    in this category. When more lowerings are added (e.g. QuantizeV2Op),
    they should be added to this pass.
  }];

  let constructor = "TF::CreateLowerQuantizedPass()";
}