similar to: Work on DAG Isel for TableGen and compiler

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

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

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

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

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.

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

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

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

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

I took a look at all the OPC_SwitchOpcode operators in the matching tables. Almost every target starts with a large one, which is now cached by the interpreter. Instead, TableGen could build the opcode -> offset table. But there are also many other opcode switches with between 10 and 70 cases. To speed these up, we could embed a sorted opcode -> offset table right in the matcher code. Or,

variable_ops is used in the tablegen defs for many targets to denote instructions that a variable number of inputs, but it seems that there aren't any targets for which this results in variable elements in the instruction encoding (and thus in assembler parsing), since the tablegen generated assembly matcher ($(Target)GenAsmMatcher.inc) simply assumes that variable_ops are not to be parsed

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

A question for those of you who have developed complex TableGen files: Do you think a trace facility would be useful during debugging? The idea is to add a new statement to TableGen along these lines: trace tag : value1, value2, ... ; When encountered, the TableGen parser would display the tag along with the values of the specified value1, value2, etc. The tag is an identifier that makes it

I included the ability to get/set an operand by name because I thought it would be easier to copy+modify an existing DAG by specifying the name of the operand you want to replace rather than having to remember its position. For example, if you want to replace the first source, isn't it easier to specify $src than remember it's the second operand? Perhaps the people actually coding these

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysRegOuts = NumResults > NumDefs &&

I'm pondering a new timing feature for TableGen and am wondering whether anyone uses the existing -time-regions option. Some instrumentation for it appears in CodeGenTarget.cpp and GICombinerEmitter.cpp but nowhere else. If no one is using it, I'll be tempted to remove it.

Hi Quentin, Thanks, that explanation makes sense. I can see that in a normal register machine, implicitly defs must be physical registers. In a stack machine like WebAssembly, though, implicit defs are known to be pushed onto the value stack just like any other defs. Slots on the value stack are represented by virtual registers until stackification, so for WebAssembly we do need the implicit defs

This is a proposal to enhance TableGen's ability to analyze and manipulate DAGs. Hopefully this will allows more complex DAGs to be built in TableGen. 1. Add a new value suffix. value(index) The value must be a DAG. The index specifies the operator or an operand, whose value is produced. The index can be 0 produce the operator 1...n produce operand by