This is an archive of the discontinued LLVM Phabricator instance.

Reduce maximum width of _ExtInt from 2^24-1 to 2^23 to workaround SelectionDAG issue.
AbandonedPublic

Authored by craig.topper on Sep 13 2021, 12:27 PM.

Details

Summary

SelectionDAG type legalization requires a power of 2 type with at
least as many bits as the _ExtInt. This power of 2 type size must
fit in 24 bits since an llvm::IntegerType will be created. This
places an effective limit of 2^23 on any integer types if they go
through SelectionDAG.

Fixes part of PR51829.

Diff Detail

Unit TestsFailed

Event Timeline

craig.topper requested review of this revision.Sep 13 2021, 12:27 PM
craig.topper created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptSep 13 2021, 12:27 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
erichkeane accepted this revision.Sep 13 2021, 12:31 PM

Changes to the tests are less intense than I would have thought! In general I'm Ok with this, I don't think anyone would really notice/mind this all that much, and since we can't actually implement this in the backends, it doesn't really make sense to have some sort of flag for this. I have a slight bit of sympathy for the backends that could consume this, but I'd think we need to have our implementation-limit be the least-common-denominator of our backends anyway.

This revision is now accepted and ready to land.Sep 13 2021, 12:31 PM
aaron.ballman accepted this revision.Sep 13 2021, 12:54 PM

LGTM modulo a request for some comments in the code. It makes me sad that we have a max number of bits specified by LLVM that's kinda useless. "You can store this many bits into this integer value, but if you attempt to add 0 to that value, it sometimes breaks" doesn't sound like a useful maximum. :-D

clang/lib/Sema/SemaType.cpp
2272–2278

I'd appreciate some extra comments here explaining why the max int bit width is insufficient.

Add comment.