[all-commits] [llvm/llvm-project] f391de: [TableGen] Store predicates in PatternToMatch as L...

Craig Topper via All-commits all-commits at lists.llvm.org
Wed Apr 28 12:09:50 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f391de8cb6f9c8ecbd3c6fcf025a2ee203db0726
      https://github.com/llvm/llvm-project/commit/f391de8cb6f9c8ecbd3c6fcf025a2ee203db0726
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2021-04-28 (Wed, 28 Apr 2021)

  Changed paths:
    M llvm/utils/TableGen/CodeGenDAGPatterns.cpp
    M llvm/utils/TableGen/CodeGenDAGPatterns.h
    M llvm/utils/TableGen/GlobalISelEmitter.cpp

  Log Message:
  -----------
  [TableGen] Store predicates in PatternToMatch as ListInit *. Add string for HwModeFeatures

This uses to be how predicates were handled prior to HwMode being
added. When the Predicates were converted to a std::vector it
significantly increased the cost of a compare in GenerateVariants.
Since ListInit's are uniquified by tablegen, we can use a simple
pointer comparison to check for identical lists.

In order to store the HwMode, we now add a separate string to
PatternToMatch. This will be appended separately to the predicate
string in getPredicateCheck. A new getPredicateRecords is added
to allow GlobalISel and getPredicateCheck to both get the sorted
list of Records. GlobalISel was ignoring any HwMode predicates
before and still is.

There is one slight change here, ListInits with different predicate
orders aren't sorted so the filtering in GenerateVariants might
fail to detect two isomorphic patterns with different predicate
orders. This doesn't seem to be happening in tree today.

My hope is this will allow us to remove all the BitVector tracking
in GenerateVariants that was making up for predicates beeing
expensive to compare. There's a decent amount of heap allocations
there on large targets like X86, AMDGPU, and RISCV.

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




More information about the All-commits mailing list