[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