This is an archive of the discontinued LLVM Phabricator instance.

[Couroutines] Modify CoroFrame materializable into a callback
ClosedPublic

Authored by dstuttard on Jan 26 2023, 5:42 AM.

Details

Summary

This change makes it possible to optionally provide a different callback to
determine if an instruction is materializable.

By default the behaviour is unchanged.

Diff Detail

Event Timeline

dstuttard created this revision.Jan 26 2023, 5:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 26 2023, 5:42 AM
dstuttard requested review of this revision.Jan 26 2023, 5:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 26 2023, 5:42 AM
This revision is now accepted and ready to land.Jan 27 2023, 10:41 AM
jsilvanus accepted this revision.Jan 30 2023, 1:11 AM

LGTM, one minor inline comment.

llvm/lib/Transforms/Coroutines/CoroSplit.cpp
1935

Maybe pass the callback by reference, both here and for the following calls?

An std::function is quite large (32 bytes for libstdc++, 40 for MSVC, 48 for libc++).

dstuttard updated this revision to Diff 495214.Feb 6 2023, 10:39 AM

Addressing reviewer comments

ChuanqiXu added 1 blocking reviewer(s): ChuanqiXu.Feb 8 2023, 6:02 PM

While this is innocent and no harmful, I prefer to land this after we found a usage for this someday. It wouldn't be a problem to do such a NFC change any times.

This revision now requires review to proceed.Feb 8 2023, 6:02 PM
dstuttard updated this revision to Diff 496092.Feb 9 2023, 4:49 AM

Rebase on fixed version

While this is innocent and no harmful, I prefer to land this after we found a usage for this someday. It wouldn't be a problem to do such a NFC change any times.

We have a use-case for this change for one of our backends.

dstuttard updated this revision to Diff 496096.Feb 9 2023, 5:13 AM

Address review commit (sorry Jannik - missed it before)

dstuttard marked an inline comment as done.Feb 9 2023, 5:13 AM

While this is innocent and no harmful, I prefer to land this after we found a usage for this someday. It wouldn't be a problem to do such a NFC change any times.

We have a use-case for this change for one of our backends.

To expand on this - we have a tool based on LLVM that already adds extra materialization options. This change was to enable generic support to extend materialization determination so that we can simplify our code to not have patches on top of upstream llvm.
I can imagine other groups having similar requirements - none of which would necessarily end up back in core llvm.

While this is innocent and no harmful, I prefer to land this after we found a usage for this someday. It wouldn't be a problem to do such a NFC change any times.

We have a use-case for this change for one of our backends.

To expand on this - we have a tool based on LLVM that already adds extra materialization options. This change was to enable generic support to extend materialization determination so that we can simplify our code to not have patches on top of upstream llvm.
I can imagine other groups having similar requirements - none of which would necessarily end up back in core llvm.

Got it. But it is still not good to modify the upstream due the requirement from the downstream. (I know this happens in llvm occasionally. But it is still not good, right?)

I think it may better for you to contribute the other materialization options you mentioned. Or you can try to add a unittest if you don't want to contribute the downstream extension to public for any reason . Otherwise, even all people here get in consensus. It is possible that other developers found the coding here is redundant and optimize it with a NFC patch directly. (This happens a lot in llvm)

dstuttard updated this revision to Diff 496412.Feb 10 2023, 3:42 AM

Add unit test demonstrating use of extra rematerialization callback

Got it. But it is still not good to modify the upstream due the requirement from the downstream. (I know this happens in llvm occasionally. But it is still not good, right?)

I think it may better for you to contribute the other materialization options you mentioned. Or you can try to add a unittest if you don't want to contribute the downstream extension to public for any reason . Otherwise, even all people here get in consensus. It is possible that other developers found the coding here is redundant and optimize it with a NFC patch directly. (This happens a lot in llvm)

Ok - I added a unit test for this - adding the other rematerializations isn't an option since they are quite project specific. (To be fair, I should probably have created a unit test in the first place).

Thanks for the unit test!

llvm/unittests/Transforms/Coroutines/ExtraRematTest.cpp
20

Maybe put the struct (or everything) into an anonymous namespace?

147

I think this should use a gtest macro, e.g. ASSERT_TRUE. Same for the other asserts.

152

Typo at the end (have been?)

dstuttard updated this revision to Diff 496430.Feb 10 2023, 4:42 AM

Thanks for the speedy review Jannik
Changes made

dstuttard marked 3 inline comments as done.Feb 10 2023, 4:42 AM
jsilvanus added inline comments.Feb 10 2023, 4:57 AM
llvm/unittests/Transforms/Coroutines/ExtraRematTest.cpp
149

I believe the intended way to pass custom messages is like this:

ASSERT_TRUE(F) << "could not find split function f.resume";
dstuttard updated this revision to Diff 496435.Feb 10 2023, 5:10 AM

Fix up ASSERT_TRUE to pass messages correctly

dstuttard marked an inline comment as done.Feb 10 2023, 5:10 AM
jsilvanus accepted this revision.Feb 10 2023, 5:12 AM

Thanks!

ChuanqiXu accepted this revision.Feb 10 2023, 9:00 PM

LGTM. Thanks.

This revision is now accepted and ready to land.Feb 10 2023, 9:00 PM
This revision was landed with ongoing or failed builds.Feb 13 2023, 3:07 AM
This revision was automatically updated to reflect the committed changes.