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.

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 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

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

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

Hi all, We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it. *** Why Is That? *** We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption. In particular, 1. The APIs are still evolving and can still possibly change significantly 2. The TableGen backend to reuse the existing SD

Hi, I would like your opinions on the contract we have between the LLVM IR and the backends. * Context * Right now, the backends are supposed to be able to perform instruction selection on any valid LLVM IR. Although this is *not* something I want to change for GlobalISel, I thought I brought that up on the mailing list to discuss the implications. In particular, in the past, some people

> On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at braunis.de> wrote: > > >> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I would like your opinions on the contract we have between the LLVM IR and the backends. >> >> >> * Context * >> >>

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 &&