search for: matchertables

Is the algorithm described in the article "Near-Optimal Instruction Selection on DAGs (https://llvm.org/pubs/2008-CGO-DagISel.html)" really used in llvm instruction selection? I've studied implementation (SelectionDAGISel.cpp) and I see that instructions are selected by target specific MatcherTable generated by llvm-tblgen. In the implementation the first matching pattern from

I have a few questions about matching in the selector. 1. Why does the size of the MatcherTable greatly exceed the number of patterns defined in the target description? If it simply contains all the variants of the patterns then what is the encoding of these entries ? 2. Is there a simple way to extract the root opcode of a pattern from the MatcherTable entry ? 3. I believe the entries in the

...tion algorithm for DAG instead of tree matching. My question is, according to the paper, each tile in DAG has a cost value which is used in dynamic programming process and CSE decisions. But in TableGen files, I didn't find any field recording cost values or similar properties. I know that the MatcherTables in generated TableGen include files act like a byte code interpreter which perform bottom-up selection, resembles to bottom-up dynamic programming. But if the generated MatcherTables are really used for performing bottom-up dynamic programming selection, it still needs a cost model to help it makin...

> Mehdi Amini <mehdi.amini at apple.com> 於 2016年11月30日 上午5:14 寫道： > >> >> On Nov 29, 2016, at 4:02 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time matrices of

Hi Ivan, Matcher table generation which is implemented in utils/DAGISelEmitter.cpp does use heusiristics like number of instructions which a pattern will cover, latency (not the one which Targets scheduling defines) while emitting the candidate patterns for a give dag node. Current implications may not be implication of algorithm in toto though. Thanks, Jatin On Wednesday, March 28, 2018, Ivan

LLVM performs a greedy, bottom-up instruction selection. At each step, it selects the pattern that will absorb the most nodes (roughly: the order can be tweaked by the target using AddedComplexity, which is often used to model the idea that a particular pattern is more profitable than it would otherwise appear). I don’t personally think there is that much to gain from an algorithm significantly

...ng. >> >> My question is, according to the paper, each tile in DAG has a cost value >> which is used in dynamic programming process and CSE decisions. But in >> TableGen files, I didn't find any field recording cost values or similar >> properties. I know that the MatcherTables in generated TableGen include >> files act like a byte code interpreter which perform bottom-up selection, >> resembles to bottom-up dynamic programming. But if the generated >> MatcherTables are really used for performing bottom-up dynamic programming >> selection, it still...

...d of tree > matching. > > My question is, according to the paper, each tile in DAG has a cost value > which is used in dynamic programming process and CSE decisions. But in > TableGen files, I didn't find any field recording cost values or similar > properties. I know that the MatcherTables in generated TableGen include > files act like a byte code interpreter which perform bottom-up selection, > resembles to bottom-up dynamic programming. But if the generated > MatcherTables are really used for performing bottom-up dynamic programming > selection, it still needs a cost mo...

Hi, Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time matrices of codegen(llc -time-passes), you'll find that the most time consuming task is actually instruction selection(40~50% of time) instead of optimization passes(10~0%). That's why we're trying to parallelize the (target-independent) instruction selection process

...d of tree > matching. > > My question is, according to the paper, each tile in DAG has a cost value > which is used in dynamic programming process and CSE decisions. But in > TableGen files, I didn't find any field recording cost values or similar > properties. I know that the MatcherTables in generated TableGen include > files act like a byte code interpreter which perform bottom-up selection, > resembles to bottom-up dynamic programming. But if the generated > MatcherTables are really used for performing bottom-up dynamic programming > selection, it still needs a cost mo...

> On Nov 29, 2016, at 1:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Nov 29, 2016, at 4:02 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

Hi there, I try to JIT compile some bitcode and seeing the following error: LLVM ERROR: Cannot select: 0x28ec830: ch,glue = X86ISD::CALL 0x28ec7c0, 0x28ef900, Register:i32 %EDI, Register:i8 %AL, RegisterMask:Untyped, 0x28ec7c0:1 0x28ef900: i32 = X86ISD::Wrapper TargetGlobalAddress:i32<void (i8*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec520: i32 = TargetGlobalAddress<void (i8*, ...)*

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

- my old email address. The ISA_* classes might not be the best choice for this. There's an overall hierarchy and ordering to the ISA_* classes since they represent the generations of the MIPS ISA. If these extensions are available in Loongson chips based on MIPS32r1 and MIPS32r2 for example, it becomes difficult to describe with ISA_* classes without duplicating instruction definitions or