[llvm-dev] Musings on the TableGen -emit-dag-isel backend

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 13 04:53:58 PST 2020


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 stream. Or I could conditionalize all the output on another function parameter so it isn't done at all.
> 
> I'm not convinced that anyone would notice a 4% increase in the size of the matching table, but I don't think that's my call.

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. ;-)
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the llvm-dev mailing list