Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cppmangle.d: Fix substitution logic in writeBasicType() #9138

Merged
merged 1 commit into from
Dec 30, 2018

Conversation

ibuclaw
Copy link
Member

@ibuclaw ibuclaw commented Dec 25, 2018

Specifically fixes nullptr_t and target-specific built-in type mangling (correcting patch in #9129) @JohanEngelen.

Later on, this will also work for char16_t and char32_t as well.

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @ibuclaw!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#9138"

@thewilsonator
Copy link
Contributor

runnable/extra-files/cppb.cpp:474:19: error: unknown type name 'nullptr_t'; did you mean 'std::nullptr_t'?
void testnullnull(nullptr_t n1, nullptr_t n2)
                  ^~~~~~~~~
                  std::nullptr_t

@thewilsonator
Copy link
Contributor

Its also only defined in C++11 with all the fun dealing with that entails.
#9130 should make that doable without pulling hair.

src/dmd/cppmangle.d Outdated Show resolved Hide resolved
if (auto tm = target.cppTypeMangle(t))
{
bool builtin = (t.ty == Tvoid || t.ty == Tbool || t.isintegral() || t.isreal());
writeBasicType(t, tm.toDString(), builtin);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need to do a strlen, I suggest having target.cppTypeMangle() return a string in the first place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function is implemented in c++, which doesn't know how D strings are passed around.

Can just drop the [] from writeBasicType instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

( Reversing the order (first check target.cppTypeMangle before doing the hardcoded switch) is helpful: backends no longer need to modify dmdfe source to override the hardcoded mangles. Nice. )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it was originally, but then it got refactored. This is just a partial revert to former behaviour.

@WalterBright
Copy link
Member

I don't see where Tnull is handled in the code.

Most (all?) of the new code seems to be a refactoring, I'm not seeing where the fixes are. I'd prefer to see such significant refactoring done separately.

Also, the refactoring is doing a lot of replacing single character literals with strings. This looks slightly nicer, but comes at a cost in code bloat and speed. dmd has slowed down over time due to an accumulation of these sorts of things. I wrote the code the original way for speed reasons.

@JohanEngelen
Copy link
Contributor

About performance: to me it looks like the new code is less performant (e.g. always doing a call to target.cppMangle where in most cases it won't be needed), but if mangling of C++ symbols is a measurable performance bottleneck I'd be very happy ;-) (what I mean is: we don't call these functions so many times, and dynamic alloc+resizing of the mangling string is probably the largest perf issue)

src/dmd/cppmangle.d Outdated Show resolved Hide resolved
src/dmd/cppmangle.d Outdated Show resolved Hide resolved
@ibuclaw ibuclaw force-pushed the cppmangle2 branch 2 times, most recently from d4f55d4 to edf25f4 Compare December 27, 2018 20:29
@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 27, 2018

I don't see where Tnull is handled in the code.

Tnull is mangled Dn.

Most (all?) of the new code seems to be a refactoring, I'm not seeing where the fixes are. I'd prefer to see such significant refactoring done separately.

This is a refactor. That it fixes two broken mangling cases is a side effect of this change.

Also, the refactoring is doing a lot of replacing single character literals with strings. This looks slightly nicer, but comes at a cost in code bloat and speed. dmd has slowed down over time due to an accumulation of these sorts of things. I wrote the code the original way for speed reasons.

Well speed or no, it was still producing bad symbols by assuming that all two character or greater mangles are non-fundamental types.

@ibuclaw ibuclaw force-pushed the cppmangle2 branch 2 times, most recently from 0da051d to 6461f11 Compare December 27, 2018 20:50
@WalterBright
Copy link
Member

This is a refactor. That it fixes two broken mangling cases is a side effect of this change.

May I reiterate that fixing and refactoring should be different PRs. I can't find the fixes amid the refactorings. I know it's inconvenient for you, but the payoff is worth it, especially since the mangling code has been a prolific source of problems and regressions.

@WalterBright
Copy link
Member

if mangling of C++ symbols is a measurable performance bottleneck I'd be very happy

I want to make sure it isn't. I haven't profiled it in years, but in the past it certainly has been measurable. An awful lot of symbols go through the mangler, although to be fair fewer of them go specifically through the C++ mangler.

@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 28, 2018

May I reiterate that fixing and refactoring should be different PRs. I can't find the fixes amid the refactorings. I know it's inconvenient for you, but the payoff is worth it, especially since the mangling code has been a prolific source of problems and regressions.

Other than removing the test, I don't see how. By forcing the caller to say whether they are a fundamental type or not just so happens to fix Tnull mangling, because when I looked at it, it turned out to be using writeBasicType inappropriately.

@ibuclaw ibuclaw force-pushed the cppmangle2 branch 3 times, most recently from ae59c7a to 67fc6c2 Compare December 29, 2018 18:59
@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 29, 2018

Moved decision from caller of writeBasicType to callee.

Unlike the original patch that was questionably slower, this is definitely slower. :-)

@ibuclaw ibuclaw force-pushed the cppmangle2 branch 2 times, most recently from b472d0b to 19f1dfc Compare December 29, 2018 19:16
Specifically fixes nullptr_t and target-specific mangling.

Later on, this will also work for char16_t and char32_t as well.
@@ -727,6 +727,19 @@ void test16()
static assert(0);
}

/****************************************/
/+ FIXME: Requires C++11 compiler.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the time has come to segment tests by C++ version.
You can create a separate file, let's say cppa_11.d, and use:

 // EXTRA_CPP_SOURCES: cppa_11.cpp
// CXXFLAGS: -std=c++11

To test C++11-specific behaviors

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice idea though it can probably be done as another PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be rushing to merge PRs without any tests in them.
And it's not a large change to do either, moving a bit of code to a new file, so I really don't understand the hurry.

@thewilsonator
Copy link
Contributor

Semaphore fails due to reproducible build differences.

@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 30, 2018

Semaphore fails due to reproducible build differences.

If only the diffing tool was smarter to actually pinpoint where it went wrong.

However, question...

Is it diffing host vs. newly built? Or newly built vs. bootstrap?

@thewilsonator
Copy link
Contributor

(That was more a reminder to me not to bother to look again before merging it, not something that needs to be fixed.)

If only the diffing tool was smarter to actually pinpoint where it went wrong.

It would be nice.

Is it diffing host vs. newly built? Or newly built vs. bootstrap?

Don't know, don't really care. Reproducible build are nice in theory, but we're not building super secure software so it doesn't really matter.

@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 30, 2018

Don't know, don't really care.

Well, I ask because the former points to a bug in the CI script (it will fail if you make any ABI fixes), and the latter points to a bug introduced by this PR. :-)

@thewilsonator
Copy link
Contributor

It happens frequently enough that I've lost count of the number of PRs I've merged that have had a similar issues, probably the tests fault, but as I said, its not a particularly meaningful test.

@ibuclaw
Copy link
Member Author

ibuclaw commented Dec 30, 2018

I've just pulled the logs from semaphore, extracted all symbols from the diff and compared, and found nothing whatsoever.

Maybe what we're seeing is the infamous feature I've heard about where dmd backend has a built-in stopwatch, and will stop optimizing and skip straight to writing object code if it spends too long going through all passes.

@thewilsonator
Copy link
Contributor

I've just pulled the logs from semaphore, extracted all symbols from the diff and compared, and found nothing whatsoever.

Hence why I ignore that test.

Maybe what we're seeing is the infamous feature I've heard about where dmd backend has a built-in stopwatch, and will stop optimizing and skip straight to writing object code if it spends too long going through all passes.

Maybe, all I know is that the SNR on that test is shockingly bad.

@thewilsonator thewilsonator merged commit 7ae7a21 into dlang:master Dec 30, 2018
@ibuclaw ibuclaw deleted the cppmangle2 branch December 31, 2018 09:05
@JohanEngelen
Copy link
Contributor

I'd very much appreciate enabling the C++11 tests.

@Geod24
Copy link
Member

Geod24 commented Jan 3, 2019

I'd very much appreciate enabling the C++11 tests.

#9185

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants