llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

http://llvm.org

Other

28.32k stars 11.69k forks source link

[GISel] Add variable operand MIR patterns #87459

Closed Pierre-vh closed 2 months ago

Pierre-vh commented 6 months ago

Description

Allow "parameter packs" or similar for MIR patterns to support matching any number of operands. e.g. G_BUILD_VECTOR has a variable number of operands, and currently we can only write patterns for a fixed number of operands.

Optional goals:

Accessing the front or back of the variadic operands list
Accessing the nth item of the variadic operands list
Additional constraints such as min/max number of arguments.
Rewriting the variadic operands
- This isn't as important I think, I can't think of many patterns that'd need a variadic instruction in and out. Do it if it's trivial?

Syntax suggestion

G_BUILD_VECTOR $x, $y, varargs:$others
G_BUILD_VECTOR $x, $y, varargs<2,4>:$others // 2 to 4 operands

Potential issues

Should the variadic operand(s) act as "one or more" or "zero or more"? e.g. in the first example above, should a 2-operand BUILD_VECTOR be allowed, or does varargs:$others implies at least 3 operands in total?

87194

tschuett commented 6 months ago

I have two different use-cases: Given a G_EXTRACT_VECTOR_ELT, I want to express in Mir that the source is a G_BUILD_VECTOR.

In https://github.com/llvm/llvm-project/pull/67358, it is the opposite. I want to express that the uses of a G_BUILD_VECTOR are binops.

arsenm commented 6 months ago

Should the variadic operand(s) act as "one or more" or "zero or more"? e.g. in the first example above, should a 2-operand BUILD_VECTOR be allowed, or does varargs:$others implies at least 3 operands in total?

I would assume a pattern without mentioning varargs would work for however many operands are listed. I would then expect varargs to be 1 or more

tschuett commented 3 months ago

Are there any plans?

G_BUILD_VECTOR $bv
G_TRUNC $root, $bv

A cheap version would be nice to push the truncate through the build vector.

arsenm commented 2 months ago

cc @shiltian

Pierre-vh commented 2 months ago

Are there any plans?
G_BUILD_VECTOR $bv
G_TRUNC $root, $bv
A cheap version would be nice to push the truncate through the build vector.

I haven't looked at this seriously yet, but I have some bandwidth now so I'll try to have a look.

What is the scope of the use cases? Once the varargs are matched, what kind of feature do you (and @arsenm) need to be able to do?

How do you want to manipulate them, both in MIR patterns and C++ expansions?
- Should we be able to emit an iterator range for the varargs to use in C++?
- Should we be able to reuse an individual element of the pack, such as the head/tail or even specific indexes, to match it elsewhere in another instruction?
Is rewriting needed?

tschuett commented 2 months ago

A really cheap first step would be nice to have. I just want to express the pattern truncate(build_vector) in MIR. The rest can be in C++: https://github.com/llvm/llvm-project/blob/430b2545032db9de7898444502915f89e20f7c4c/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L15038

In C++, I would then see a G_TRUNC and a G_BUILD_VECTOR. We can use the standard methods for access.