This is an archive of the discontinued LLVM Phabricator instance.

[CGExpr] Use getCharWidth() more consistently in CCGExprConstant. NFC
ClosedPublic

Authored by bjope on Jan 19 2021, 9:19 AM.

Details

Summary

Most of CGExprConstant.cpp is using the CharUnits abstraction
and is using getCharWidth() (directly of indirectly) when converting
between size of a char and size in bits. This patch is making that
abstraction more consistent by adding CharTy to the CodeGenTypeCache
(honoring getCharWidth() when mapping from char to LLVM IR types,
instead of using Int8Ty directly).

Diff Detail

Event Timeline

bjope requested review of this revision.Jan 19 2021, 9:19 AM
bjope created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 19 2021, 9:19 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

As far as i recall, all RFC's about LLVM support for non-8-bit char targets didn't end in favor of the proposal
I'd say that until there's general consensus/buy-in (including testing path), cleaning stuff up will only confuse things.
CC @jfb

As far as i recall, all RFC's about LLVM support for non-8-bit char targets didn't end in favor of the proposal
I'd say that until there's general consensus/buy-in (including testing path), cleaning stuff up will only confuse things.
CC @jfb

Well, I haven't even added reviewers. But if it hurts so much maybe I should abandon it ;-)

But from my point of view this patch isn't really adding non-8-bit char support. But there is an abstraction in clang (such as ASTContext) with getCharWidth(), toCharUnitsFromBits() etc. And it is confusing when things don't add up (such as calculating the number of chars using toCharUnitsFromBits(), indirectly using getCharWidth(), and then later ignoring it and assuming that the char width is 8. I don't see how being more consistent is more confusing.

bjope retitled this revision from [CGExpr] Honor getCharWidth() in ConstantAggregateBuilderUtils to [CGExpr] Use getCharWidth() more consistently in ConstantAggregateBuilderUtils. NFC.Jan 19 2021, 11:10 AM
bjope edited the summary of this revision. (Show Details)

I don't mind generally abstracting Clang to handle this better.

clang/lib/CodeGen/CodeGenModule.h
1229 ↗(On Diff #317603)

Please just add a CharTy to CodeGenTypeCache.

bjope updated this revision to Diff 318135.Jan 21 2021, 2:00 AM

Updated to add CharTy to the CodeGenTypeCache (based on review feedback).

bjope retitled this revision from [CGExpr] Use getCharWidth() more consistently in ConstantAggregateBuilderUtils. NFC to [CGExpr] Use getCharWidth() more consistently in CCGExprConstant. NFC.Jan 21 2021, 2:01 AM
bjope edited the summary of this revision. (Show Details)
bjope added a comment.Jan 21 2021, 9:43 AM

@lebedev.ri : I think I need your blessing as well on this, considering your earlier concerns. Is it still just confusing? (I doubt that we want/can replace all uses of getCharWidth/getIntWidth etc in clang with integers)

lebedev.ri added a comment.EditedJan 21 2021, 10:01 AM

I don't particularly want/like to straight-up derail this,
but my *personal* opinion still hasn't changed, and it is not unsubstantiated,
see https://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html,
https://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html, etc,

I think the fact that last *two* recent-ish RFC's on this didn't succeed
suggests that a third one might be in order, perhaps with better arguments
this time, or maybe the previous opponents will just not block this..

TBN, i don't dislike the feature per-se, at least without seeing the full impact of the cleanup.

rjmccall accepted this revision.Jan 21 2021, 11:37 AM

Clang has generally made a point of trying to be as neutral about CHAR_BITS as it can be, even though LLVM has not. As the code owner of this code, I view this as a fix consistent with that, and I consider it acceptable to land.

Of course, if you are pursuing these patches out of an expectation that you'll eventually get Clang to support compiling targets with non-8-bit-addressing, you need to understand that (at least for most cases) that depends on LLVM supporting such targets, and so far the LLVM community has been pretty strongly opposed to that idea. But Clang has *internally* already accepted the abstraction costs of CharUnits, and we should to be as consistent as possible about that in our own code.

This revision is now accepted and ready to land.Jan 21 2021, 11:37 AM
This revision was landed with ongoing or failed builds.Jan 22 2021, 12:15 PM
This revision was automatically updated to reflect the committed changes.