This is an archive of the discontinued LLVM Phabricator instance.

[Coroutines] Add `llvm.coro.align`, `llvm.coro.raw.frame.ptr.offset` and `llvm.coro.raw.frame.ptr.addr` intrinsics
AbandonedPublic

Authored by ychen on May 9 2021, 7:24 PM.

Details

Summary

llvm.coro.align returns the alignment of the coroutine frame in bytes.

llvm.coro.raw.frame.ptr.offset returns the byte offset of the raw memory block address (returned by the allocator) in the over-aligned coroutine frame. This is for switched-resume scheme only. The returned value is undefined if the coroutine frame is not over-aligned.

llvm.coro.raw.frame.ptr.addr returns the address storing the raw frame address. The returned address is either an alloca (before llvm.coro.begin) or a coroutine frame field (after llvm.coro.begin).

Diff Detail

Event Timeline

ychen created this revision.May 9 2021, 7:24 PM
ychen requested review of this revision.May 9 2021, 7:24 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 9 2021, 7:24 PM
ychen retitled this revision from [Coroutines] Add `llvm.coro.align` and `llvm.coro.get.raw.frame.addr` intrinsics to [Coroutines] Add `llvm.coro.align` and `llvm.coro.raw.frame.ptr.offset` intrinsics.May 9 2021, 7:31 PM
ychen edited the summary of this revision. (Show Details)
ychen updated this revision to Diff 343955.May 9 2021, 7:35 PM
  • Fix doc.

The overall patch looks good to me. It seems like this patch did nothing without D97915. And it is different from normal NFC changes. I am not sure if it is more proper to merge this with D97915.

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

It looks like Shape.SwitchLowering.FramePtrOffset is used but never set other than initializing.

ychen added a comment.May 11 2021, 4:57 PM

The overall patch looks good to me. It seems like this patch did nothing without D97915. And it is different from normal NFC changes. I am not sure if it is more proper to merge this with D97915.

It could be merged with D97915. I was afraid the patch size would be too big to make reviewing inconvenient. I'll add a standalone test for added intrinsics to make the patch self-ccontain.

ychen updated this revision to Diff 344601.May 11 2021, 5:02 PM
  • Add llvm.coro.raw.frame.ptr.addr to help storing raw frame address during allocation. llvm.coro.raw.frame.ptr.offset cannot be used during allocation because coroutine lowering would overwrite the raw frame address field with %alloc.frame.ptr alloca after llvm.coro.begin. The malloc returned address should be stored to %alloc.frame.ptr instead of the raw frame address field directly.
  • Add tests for added intrinsics.
ychen retitled this revision from [Coroutines] Add `llvm.coro.align` and `llvm.coro.raw.frame.ptr.offset` intrinsics to [Coroutines] Add `llvm.coro.align`, `llvm.coro.raw.frame.ptr.offset` and `llvm.coro.raw.frame.ptr.addr` intrinsics.May 11 2021, 5:05 PM
ychen edited the summary of this revision. (Show Details)
ychen updated this revision to Diff 344647.May 11 2021, 8:35 PM
ychen edited the summary of this revision. (Show Details)
  • Fix a test typo.
ChuanqiXu added inline comments.May 12 2021, 3:05 AM
llvm/docs/Coroutines.rst
964

If this is only valid under switch-resume coroutines, we need to mark them in the doc.

llvm/lib/Transforms/Coroutines/CoroFrame.cpp
795–824

If the new added intrinsic is intended for all APIs, we should move them out of the if blocks.

819

If we add a new alloca simply, it shouldn't work properly. For example,

void foo() {
     %a = alloca i32
     %b = alloca i32
     %promise = alloca PromiseType 
}

The frame we want may be:

%FrameType = type { [i8 x num of padding], resume_fn, destroy_fn, %promise, i32, i32, index}

However, if we simply add a new alloca with type i8*, we may get the FrameType with:

%FrameType = type { resume_fn, destroy_fn, %promise, i32, i32, i32*, index}

I don't think this could solve our problems. Or does it work only with the successor patches?

ychen added a comment.May 12 2021, 5:05 PM

Thanks for the review!

llvm/docs/Coroutines.rst
964

It's general, i.e not specific to switch-resume coroutines.

llvm/lib/Transforms/Coroutines/CoroFrame.cpp
795–824

It is only supported for switched-resume coroutines. (mentioned in the doc)

819

Yes, following patch D97915 would do the overallocate&adjust frame start address. Here checks if (1) the frame is overaligned and (2) if llvm.coro.raw.frame.ptr.* intrinsics are used. If both are true, create an alloca that goes to the frame. coro-frame-overalign.ll test has the details.

ChuanqiXu added inline comments.May 12 2021, 7:37 PM
llvm/lib/Transforms/Coroutines/CoroFrame.cpp
795–824

hmmm, doesn't it conflict with the replies above? Or does it mean these intrinsics could be used generally by design but we just don't support them for other ABI now?

819

So does it mean this code would only work correctly if D97915 applies? It is a little bit weird for me. I understand that it would be clear er if we split a patch into separate ones. But it would be odd if these patches depends on each other.

ychen added inline comments.May 17 2021, 5:33 PM
llvm/lib/Transforms/Coroutines/CoroFrame.cpp
819

So does it mean this code would only work correctly if D97915 applies?

No. This patch only lowers the new intrinsics under switched-resume ABI. Without D97915, there are no uses of these new intrinsics, so this patch basically no-op before D97915 applies.

ChuanqiXu added inline comments.May 17 2021, 9:10 PM
llvm/lib/Transforms/Coroutines/CoroFrame.cpp
819

It is still weird for me. It looks like these codes are redundant if we don't applies D97915. I am still prefer to merge this with D97915.

It looks like that other reviewers are not available at this time. I am curious about the alignment problem for coroutine frame since I met confusing regression problem due to alignment mismatch in the past. Although the condition to trigger the alignment mismatch problem is not common (it requires the user to specify the alignment for a variable with alignment large than 16), I am desired to complete the (series) patch(es). So again, it looks better for me to merge this with D97915 to review and test. How do you think about it @ychen ?

It looks like that other reviewers are not available at this time. I am curious about the alignment problem for coroutine frame since I met confusing regression problem due to alignment mismatch in the past. Although the condition to trigger the alignment mismatch problem is not common (it requires the user to specify the alignment for a variable with alignment large than 16), I am desired to complete the (series) patch(es). So again, it looks better for me to merge this with D97915 to review and test. How do you think about it @ychen ?

Thanks for taking another look. Sure, I'll update the patch tomorrow.

ychen abandoned this revision.Sep 23 2022, 5:28 PM

327141f was landed as an alternative.

Herald added a project: Restricted Project. · View Herald TranscriptSep 23 2022, 5:28 PM