[PATCH] D65994: Extended FPOptions with new attributes

Serge Pavlov via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 11 04:42:00 PDT 2020


It is a matter of taste, but for me it looks strange to develop complex and
error-prone system to save 7 bits at expense of readability and
maintainability. My observations show that clang AST consumes much less
memory than llvm objects.

FPOption could be shared between user using something like shared_ptr, but
it means expenses of 64 bit for a pointer. Don't know if it makes sense...


Thanks,
--Serge


On Wed, Mar 11, 2020 at 6:30 PM Sam McCall via Phabricator <
reviews at reviews.llvm.org> wrote:

> sammccall added a comment.
>
> This patch increased the used size of BinaryOperator by 5 bits.
> Those bits were all padding, but now BinaryOperatorBitfields is completely
> full at 32 bits and we can't add any new bits to Stmt without increasing
> BinaryOperator by 8 bytes. (See D75443 <https://reviews.llvm.org/D75443>
> and D54526 <https://reviews.llvm.org/D54526> for the optimization this
> would revert).
>
> To squeeze in the new bit I'm planning to suggest squeezing getInt() to 7
> bits (it encodes 3x2x5x3 = 90 states, so this is possible) but I'm not
> really familiar with this domain - if many of the 90 states are not
> possible it'd probably be useful to have some more bits back :-)
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D65994/new/
>
> https://reviews.llvm.org/D65994
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200311/09512336/attachment-0001.html>


More information about the cfe-commits mailing list