search for: opc_switchopcod

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

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

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, TARGET_VAL(ISD::TargetGlobalAddress), > /*2245*/ OPC_MoveParent, > /*2246*/...

On 1/15/2016 1:08 PM, Phil Tomson wrote: > > Ah, I see, the defm is a multi-class so I needed to change it to: > > def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)), > (LOADI64_RI tglobaladdr:$addr, 0)>; > // Match load from a relocatable address to a load with GRP: > def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), > (LOADI64_RI

...It's not necessarily about the total size, but cache pressure is an issue. 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 linear list of cases, often hundreds of them (depending on the target). A binary search over a jump table would be *much* better for those. Cheers, Nicolai > I have plenty to do while waiting for more comments. ;-) > > ____________________________________________...

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

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