[all-commits] [llvm/llvm-project] 0cb44c: [AArch64][NFC] Fix ComplexPattern types conflictin...

Thu Dec 2 23:05:23 PST 2021

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0cb44cfbb7616e5fb9a0c19c8784cf0fb5cfc2e3
      https://github.com/llvm/llvm-project/commit/0cb44cfbb7616e5fb9a0c19c8784cf0fb5cfc2e3
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-12-03 (Fri, 03 Dec 2021)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
    M llvm/lib/Target/AArch64/SVEInstrFormats.td

  Log Message:
  -----------
  [AArch64][NFC] Fix ComplexPattern types conflicting with uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review,
but these are all the type conflicts found (all legitimate) by my
locally-patched TableGen.

Reviewed By: paulwalker-arm

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

  Commit: 3ee56eed2fc2c964c203b6e4274da1f32f75d0c0
      https://github.com/llvm/llvm-project/commit/3ee56eed2fc2c964c203b6e4274da1f32f75d0c0
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-12-03 (Fri, 03 Dec 2021)

  Changed paths:
    M llvm/lib/Target/AMDGPU/BUFInstructions.td
    M llvm/lib/Target/AMDGPU/FLATInstructions.td
    M llvm/lib/Target/AMDGPU/SIInstrInfo.td
    M llvm/lib/Target/AMDGPU/SMInstructions.td

  Log Message:
  -----------
  [AMDGPU][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AMDGPU currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR, and where using an iPTR instead of
a fixed-width integer type matters. With my locally-patched TableGen,
none of these mismatches result in type contradictions, but do change
the patterns and cause various failures to select. These changes to the
ComplexPatterns' types reflect how they are actually used, result in
bit-for-bit identical TableGen output (without my local TableGen patch),
and ensure that with improved type inference AMDGPU's backend will
continue to work.

Reviewed By: arsenm

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

  Commit: a3530dc19980095dca687ea0b660821a67628403
      https://github.com/llvm/llvm-project/commit/a3530dc19980095dca687ea0b660821a67628403
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-12-03 (Fri, 03 Dec 2021)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64InstrFormats.td
    M llvm/lib/Target/AArch64/SVEInstrFormats.td

  Log Message:
  -----------
  [AArch64][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AArch64 currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR. The cases that lead to type
contradictions are separated out in D108759, but there are additional
differences to the TableGen output when using my locally-patched
TableGen. None of these appear to matter, at least for passing all the
CodeGen tests, but it's safer to avoid such changes (and similar changes
were causing issues on some AMDGPU tests, causing failures to select).
Changing these additional ComplexPatterns to use iPTR rather than i64
ensures that the TableGen output remains bit-for-bit identical (compared
to without having this patch and my TableGen patch, as well as the
intermediate state of having this patch but not my TableGen patch), and
more accurately captures the higher-level meaning of these patterns.

Reviewed By: david-arm

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

  Commit: c1048e3eb920958bb48723c5b996f1877554575f
      https://github.com/llvm/llvm-project/commit/c1048e3eb920958bb48723c5b996f1877554575f
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-12-03 (Fri, 03 Dec 2021)

  Changed paths:
    A llvm/test/TableGen/dag-isel-complexpattern.td
    M llvm/utils/TableGen/CodeGenDAGPatterns.cpp
    M llvm/utils/TableGen/CodeGenTarget.cpp
    M llvm/utils/TableGen/CodeGenTarget.h

  Log Message:
  -----------
  [TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. This addresses that
discrepancy. The test case is not representative of most real-world uses
but is sufficient to demonstrate inference is working.

Some of these uses also make use of ValueTypeByHwMode rather than
SimpleValueType and so the existing type inference is extended to
support that alongside the new type inference.

There are also currently various cases of using ComplexPatterns with an
untyped type, but only for non-leaf nodes. For compatibility this is
permitted, and uses the old behaviour of not inferring for non-leaf
nodes, but the existing logic is still used for leaf values. This
remaining discrepancy should eventually be eliminated, either by
removing all such uses of untyped so the special case goes away (I
imagine Any, or a more specific type in certain cases, would be
perfectly sufficient), or by copying it to the leaf value case so
they're consistent with one another if this is something that does need
to keep being supported.

All non-experimental targets have been verified to produce bit-for-bit
identical TableGen output with this change applied.

Reviewed By: kparzysz

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

Compare: https://github.com/llvm/llvm-project/compare/62c74d496bb4...c1048e3eb920