This is an archive of the discontinued LLVM Phabricator instance.

[clang/Basic] Make TargetInfo.h not use DataLayout again
ClosedPublic

Authored by thakis on Apr 19 2021, 10:58 AM.

Details

Summary

Reverts parts of https://reviews.llvm.org/D17183, but keeps the
resetDataLayout() API and adds an assert that checks that datalayout string and
user label prefix are in sync.

Approach 1 in https://reviews.llvm.org/D17183#2653279
Reduces number of TUs build for 'clang-format' from 689 to 575.

I also implemented approach 2 in D100764. If someone feels motivated
to make us use DataLayout more, it's easy to revert this change here
and go with D100764 instead. I don't plan on doing more work in this
area though, so I prefer going with the smaller, more self-consistent change.

Diff Detail

Event Timeline

thakis created this revision.Apr 19 2021, 10:58 AM
thakis requested review of this revision.Apr 19 2021, 10:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 19 2021, 10:58 AM
thakis edited the summary of this revision. (Show Details)Apr 19 2021, 12:26 PM

Of the three people who commented on D17183, you and I are on the only ones in favor of this approach. I think @echristo and @jyknight both preferred approach 2. I'd like to get at least an agreement to disagree from one of them before approving this.


I remember now that the last time this came up, we wanted to preserve the ability for the frontend to generate IR for any target, even if it has no registered backend. This means we don't need REQUIRES: foo-registered-target lines in our clang IRgen tests. LLVM keeps the data layout in the backends. This dependency from clangBasic to LLVMIR wasn't a major consideration at the time. That makes me lean a little bit towards leaving this as it is.

thakis added a comment.EditedApr 19 2021, 1:36 PM

Of the three people who commented on D17183, you and I are on the only ones in favor of this approach. I think @echristo and @jyknight both preferred approach 2. I'd like to get at least an agreement to disagree from one of them before approving this.

That's 50% in people, and 15/24 voting by changes that landed in clang/ since start of year ;) Don't know why 2/4 is "only".

I'm also not dismissing approach 2: I implemented it as well, and it's ready-to-go as soon as someone wants to pursue the direction mentioned there. If someone wants to do that, I don't have a problem with it, but until then this here is simpler and more self-consistent since it preserves the original design of TargetInfo.

Of the three people who commented on D17183, you and I are on the only ones in favor of this approach. I think @echristo and @jyknight both preferred approach 2. I'd like to get at least an agreement to disagree from one of them before approving this.

That's 50% in people, and 15/24 voting by changes that landed in clang/ since start of year ;) Don't know why 2/4 is "only".

I mean that's fair ;)

I'm also not dismissing approach 2: I implemented it as well, and it's ready-to-go as soon as someone wants to pursue the direction mentioned there. If someone wants to do that, I don't have a problem with it, but until then this here is simpler and more self-consistent since it preserves the original design of TargetInfo.

how about some historical context. I'm reasonably certain I was one of the motivators behind this change. The prior state often lead to either very subtle bugs that were hard to diagnose without an asserts build or a fairly inscrutable assert that the front and back ends disagreed on what context a string should have. The idea was that you could then ask the "backend" how to construct up a layout for what was wanted.

As is mentioned there are tradeoffs around this though: a) it does make it harder to have clang generate code without a backend or llvm itself around, b) it does have a dependency when none existed.

So, if this is really causing some consternation then we can pull back and reinstate what we had, but it was a direction around solving a set of hard to find bugs.

Thoughts?

-eric

So, if this is really causing some consternation then we can pull back and reinstate what we had, but it was a direction around solving a set of hard to find bugs.

Thoughts?

This keeps the assert that checks that the llvm DataLayout and the user label prefix are in sync. See the NDEBUG in Mangle.cpp here-ish: https://reviews.llvm.org/D100776#change-NN4Lz7xH29fo (I measured that that assert doesn't slow down check-clang in a release+assert build too). So I don't think this regresses safety.

This keeps the assert that checks that the llvm DataLayout and the user label prefix are in sync. See the NDEBUG in Mangle.cpp here-ish: https://reviews.llvm.org/D100776#change-NN4Lz7xH29fo (I measured that that assert doesn't slow down check-clang in a release+assert build too). So I don't think this regresses safety.

It also keeps the easier-to-use resetDataLayout() API and sets the user label prefix as a 2nd (optional) arg in that function. That makes it harder to get them out of sync. And if you do get them out of sync, the assert will catch it as long as there's any test at all for that target. And if there isn't, you kind of have bigger problems :)

rnk, echristo: can we go ahead here?

rnk accepted this revision.Apr 27 2021, 4:23 PM

As is mentioned there are tradeoffs around this though: a) it does make it harder to have clang generate code without a backend or llvm itself around, b) it does have a dependency when none existed.

So, if this is really causing some consternation then we can pull back and reinstate what we had, but it was a direction around solving a set of hard to find bugs.

Thoughts?

I'm reading this as a soft, non-blocking objection. The concern that the layouts and prefix might get out of sync is addressed: there are asserts that they agree when the backends are linked in.

So, under that interpretation, and without further guidance from @echristo, I think we should go forward. If that's not the right interpretation, we can always revert.

This revision is now accepted and ready to land.Apr 27 2021, 4:23 PM

Sounds good. It's a soft objection, mostly because if nothing else it puts
us back where we were subject to some latent bugs, but perhaps not as bad
as before (though I don't find having to use an assert build reassuring ;)

Anyhow, go ahead and we'll figure out something else.

This revision was landed with ongoing or failed builds.Apr 27 2021, 7:30 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 27 2021, 7:30 PM

Landed 44e2247dcd04f3421164b085094eb575270564ba to fix LLDB. If you decide to go in a different direction again, please adjust that fix accordingly.