[llvm-dev] Why limit to the 64k on the number of SDNode operands in SelectionDAG?
Eli Friedman via llvm-dev
llvm-dev at lists.llvm.org
Tue May 26 21:34:00 PDT 2020
Is the question just “why is SDNode::NumOperands unsigned short?” It’s to save a bit of memory: two “unsigned short” values are 4 bytes, where two “size_t” values would be 16 bytes. Not sure how much it realistically matters; I don’t think anyone has really tried to evaluate the performance impact of changing that.
-Eli
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of YoungJun Lee via llvm-dev
Sent: Tuesday, May 26, 2020 8:04 PM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] Why limit to the 64k on the number of SDNode operands in SelectionDAG?
Hi, all
Why limit to the 64k on the number of SDNode operands in "Selection::createOperands()"?
If it has over the 64k on the number of SDNode, it occurs the assertion.
This commit is related the contents on above.
[SelectionDAG] Split very large token factors for loads into 64k chunks<https://github.com/llvm/llvm-project/commit/814a6794ba78ad52da499c67792602873e43d4f8>
Also, the return value type of "SDNode::getMaxNumOperands" function is "size_t", but really the return value type is fixed "unsigned short" because the type of "SDNode::NumOperands" is "unsigned short".
This commit is related the contents on above.
[SelectionDAG] Add static getMaxNumOperands function to SDNode.<https://github.com/llvm/llvm-project/commit/1b8177232813a048407bbb43eef18d7f72794b35>
Thanks.
Best Regards.
--
Young Jun Lee [dog3hk]
Tel : +82 010 3129 2621
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200527/a0e86e13/attachment.html>
More information about the llvm-dev
mailing list