This is an archive of the discontinued LLVM Phabricator instance.

[AST] Pack CallExpr
AbandonedPublic

Authored by riccibruno on Nov 18 2018, 6:24 AM.

Details

Reviewers
rjmccall
Summary

Use the newly available space in the bit-fields of Stmt to store some
data from CallExpr. This saves 8 bytes per CallExpr. This is a straightforward
patch, except that it limits the maximum number of arguments to 2^14 - 1.

The maximum number of arguments to a function call is already
limited to 16 bits because of FunctionTypeBitfields::NumParams,
which used to be 15 bits until a few month ago.

This also do not leave any space for additional bits, but after looking at
the history of CallExpr it seems that people are not adding data
here very frequently.

It would be possible to reuse some bits of the SubExprs pointer, but ideally
this pointer would be removed by storing the arguments in a trailing array.
Alternatively it would be possible to store the number of arguments in a
trailing object when it is too large.

Diff Detail

Repository
rC Clang

Event Timeline

riccibruno created this revision.Nov 18 2018, 6:24 AM

I don't think we should be reducing the number of call arguments we can support, sorry, even if 16K is a fairly absurd number that would probably trip stack overflow protections if you actually executed it. Let's try to keep it at least 64K-ish.

I don't think we should be reducing the number of call arguments we can support, sorry, even if 16K is a fairly absurd number that would probably trip stack overflow protections if you actually executed it. Let's try to keep it at least 64K-ish.

Would 15 bits be alright ? NumParams in FunctionTypeBitfields was 15 bits wide since early 2013.

You can have more arguments than parameters because of varargs. Even putting that aside, no, I think we generally shouldn't go backwards on these limits. Anyway, packing right up to the limits imposed by NumExprBits probably isn't a great idea.

riccibruno planned changes to this revision.Nov 19 2018, 11:03 AM

You can have more arguments than parameters because of varargs. Even putting that aside, no, I think we generally shouldn't go backwards on these limits. Anyway, packing right up to the limits imposed by NumExprBits probably isn't a great idea.

Alright, I think it make sense to wait until it is possible to store the arguments in a trailing array.
There are a few places where Sema resize the array of arguments in CallExpr.
From a quick look it seems it should be possible to get rid of them. For now let's mark
this "changes planned".

riccibruno abandoned this revision.Dec 17 2018, 8:26 AM

Abandoned in favor of D55771