similar to: Musings on the TableGen -emit-dag-isel backend

Would it make sense for TableGen to generate the outer OPC_SwitchOpcode offset table? At 11/13/2020 07:53 AM, Nicolai Hähnle wrote: >That said, if we are seriously thinking about the performance of the byte code, perhaps some of these opcodes should be reconsidered at a higher level anyway. > >For example: The overall bytecode always begins with an OPC_SwitchOpcode implemented as a

On 13.11.20 13:22, Paul C. Anagnostopoulos via llvm-dev wrote: > Your suggestion for two passes is indeed my plan if simply using 3-byte sizes is not acceptable. I don't want to duplicate all the logic in a second length-calculating function, so I would just have special logic for the three matching operators with children and use the existing function for the rest, passing a null output

Your suggestion for two passes is indeed my plan if simply using 3-byte sizes is not acceptable. I don't want to duplicate all the logic in a second length-calculating function, so I would just have special logic for the three matching operators with children and use the existing function for the rest, passing a null output stream. Or I could conditionalize all the output on another function

This is great! Thanks Paul! I think that the 9x reduction in compile-time is well worth the 4% size increase. TableGen's run-time has been a sore point and a source of complaints for quite some time. -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development -----Original Message----- From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul C.

This is the size of the table, not the size of the overall binary, right? I would imagine that a 4% growth in the size of the table is a substantially smaller growth in the total executable size of, say, clang. If the overall growth is minuscule (say, under 1%), then this seems like the clear path forward. I’m also optimistic that we might be able to find other ways to shrink the tables to make

A rather notorious aspect of TableGen is the time required to run the -emit-dag-isel backend on some targets, including AMDGPU and X86. I added a timing feature to TableGen and timed the AMDGPU run. ===-------------------------------------------------------------------------=== TableGen Phase Timing

I wouldn't want to be too hasty about simply removing the relaxation algorithm. The size and speed of the compiler affects all users, but the time to compile the compiler "only" affects us compiler developers. And I speak as a developer who is heavily affected by the time to compile the AMDGPU backend. One off-the-cuff idea (I haven't even looked at the code yet): could we pass

Yes, we can. But I think either solution is going eliminate the relaxation step completely, Either we will always use 3-byte sizes or we will make a first pass to size everything and then a second pass to emit the code. Either way, no relaxation is necessary. >Can we skip the relaxation step if comments aren't being emitted? >Comment emission is off by default in CMake configuration.

I have been working on improvements to TableGen's DAG Isel matcher backend. This has led me to thinking about ways to speed up the compile-time interpreter of the instruction selection matcher table. Is this worth my time, given Fast Isel and the upcoming Global Isel selector?

Hi Paul, I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my biggest pain points working on LLVM so far has been the poor error messages from the DAG ISel pattern type checker. If you could find time to improve those error

I would like to know why this patch https://reviews.llvm.org/D90973 had such a drastic size effect on the global isel tablegened matcher table for riscv. It only changed the DAG ISel table by about 15K. But the global isel table shrinks by over 200K. ~Craig On Wed, Nov 18, 2020 at 1:37 PM Paul C. Anagnostopoulos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Given that I'm

Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much at all on the Global ISel scheme, I'm tempted to work on the former and then the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I will take a look at Global ISel. Matt: Can you suggest one or two things about Global ISel that could use some work? I won't get to it quickly, but it will

Yes, the CodeGenDAGPatterns is exactly right. Try applying the patch below and rebuilding and you'll see what I mean about the error messages ;) That being said, I'm sympathetic to Matt's point about shifting effort to GlobalISel. Maybe it has similar problems you could work on? A nicer development experience would certainly be a good carrot to get me excited to switch over sooner.

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it easy to post an example? At 11/18/2020 01:55 PM, Thomas Lively wrote: >Hi Paul, > >I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

On Oct 2, 2008, at 2:19 PM, David Greene wrote: > On Thursday 02 October 2008 12:42, David Greene wrote: > >> But let's say you _could_ write such a pattern (because I can). >> The input >> DAG looks like this: >> >> 0x391a220: <multiple use> >> 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 >>

On Oct 2, 2008, at 9:37 AM, David Greene wrote: > I'm debugging some X86 patterns and I want to understand the debug > dumps from > isel better. > > Here's some example output: > > 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 > <0x39053e0:0> <sext > i32> alignment=4 srcLineNum= 10 > 0x3922c50: <multiple use> >

On Oct 2, 2008, at 2:15 PM, David Greene wrote: > On Thursday 02 October 2008 15:37, Dan Gohman wrote: >> >> Also, you can call viewGraph() from within a debugger, to view >> the graph at arbitrary point in the middle of the selection >> process. You can can even put a breakpoint on the Select >> function and view the graph as each individual instruction is

On Thursday 02 October 2008 19:22, Dan Gohman wrote: > Another trick is to place an abort() call somewhere in codegen > such that it will be called whenever the construct of interest > is processed, and then run bugpoint. If it works, the result > is a reduced testcase that's still interesting :-). That's a neat trick. I'll see if I can do that. > A feature that