Page MenuHomePhabricator
Feed Advanced Search

Today

lxfind added inline comments to D104184: [Coroutine] Properly deal with byval and noalias parameters.
Mon, Jun 14, 5:22 PM · Restricted Project
lxfind retitled D104184: [Coroutine] Properly deal with byval and noalias parameters from [Coroutine] Put byval params' value into frame, instead of just pointer to [Coroutine] Properly deal with byval and noalias parameters.
Mon, Jun 14, 5:04 PM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

However latter optimization passes could very well optimize out that copy because the copy would appear to be useless without considering what coro_suspend does, which is why we are changing BasicAA to prevent such elimination.

If an argument is just a pointer without any argument attributes, BasicAA will assume coro_suspend frees the underlying allocations. Not because it has any particular knowledge of how coro_suspend works, but because that's the default assumption for any function call with unknown semantics.

BasicAA treats arguments marked byval differently because it understands the semantics of byval: it uses escape analysis to prove an arbitrary function call can't modify the contents.


I guess in some sense, it's possible to specify a world where coro_suspend frees byval allocations. But such a world doesn't really make sense. And we'd need to audit every pass that knows anything about byval semantics, so I really don't want to go down that path.

Mon, Jun 14, 4:55 PM · Restricted Project
lxfind updated the diff for D104184: [Coroutine] Properly deal with byval and noalias parameters.

only check byval attribute

Mon, Jun 14, 4:37 PM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

From clang's perspective, what it needs to ensure is that every argument is stored in an allocation local to the callee (in other words, allocations corosplit can handle). "allocations corosplit can handle" should be either allocas, or arguments marked byval. These are pointers that don't exist in the caller, so corosplit can mess with the address in memory without worrying about code it can't see in the caller.

How do you prevent optimization passes (prior to CoroSplit) from messing up with those pointers, though?
Let's say we have an argument that's not marked with byval (due to target specifics) but is pass-by-value in C++. In Clang we could emit IR to copy the argument value to a local alloca. However latter optimization passes could very well optimize out that copy because the copy would appear to be useless without considering what coro_suspend does, which is why we are changing BasicAA to prevent such elimination.
Or are you suggesting we need to modify Clang such that every pass-by-value argument in C++ must be marked with byval?

Mon, Jun 14, 11:32 AM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

It seems that there is no stable contract to tell whether an argument is byval, and it depends on the target.
For example: https://godbolt.org/z/YcrYPbMdc
So we won't be able to fix this just in CoroSplit pass. Either we change the front-end to force all byval arguments to have byval attribute (not sure if that's possible), or we may have to conservatively go with this patch.

I'm not sure what you mean. An LLVM IR argument either has the byval attribute, or it doesn't. If it does, the allocation belongs to the callee. If it doesn't, the pointer refers to an allocation constructed in the caller. There isn't any other sense in which an argument can be "byval".

A given C++ function can have a bunch of variations in the LLVM IR signature, depending on the target, but that's not relevant here. Once clang is finished emitting IR, the C++ type signature becomes irrelevant.

Unfortunately what we really care about here is whether an argument is by-value from C++ perspective, not just whether it has a byval attribute. Let me try to explain the problem top-down and see if I got it wrong somewhere:

  1. In C++, when we call a function with a parameter passed by value, such as foo(std::move(a)), the passed value is typically a temporary value allocated at caller, and only the pointer is passed to the callee. When callee returns, the caller will be able to deallocate that temporary value's memory (in LLVM IR terms, there will be a lifetime.end marking the temporary value after the callee returns).
  2. If the callee is a normal routine (non-coroutine), the callee don't need to worry about the lifetime of the parameter because it will stay alive through the entire life cycle of the callee.
  3. However if the callee is a coroutine, the situation is different because the coroutine can return in the middle of the function and latter resume. As soon as the coroutine returns for the first time (i.e. suspended the first time), the temporary value (the pass-by-value parameter) would die in the caller. But if the callee needs to use that argument after coroutine resumption, we need to make sure that the argument value will be put on the coroutine frame (similar to allocas), so that latter access won't be accessing invalid memory.
  4. However there is one major difference between a parameter and an alloca: for a parameter that is a pointer type, we need to know whether we need to copy the value that the pointer points to to the coroutine frame, or just the pointer it self. For instance, you could call a coroutine by passing a direct pointer, and in that case we should only need to copy the pointer to the frame. But for the C++ pass-by-value arguments, we need to copy the value that the pointer points to to the frame. The question is then, during CoroSplit (the pass where we put things to the frame), are we able to tell, given an argument pointer, whether we need to copy the value or just the pointer to the frame? Knowing that a C++ pass-by-value argument doesn't necessarily end up with an argument with a byval attribute, we know that it is not possible to tell, hence we cannot deal with this properly only in CoroSplit pass.

That this sound right?

Mon, Jun 14, 9:00 AM · Restricted Project

Yesterday

lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

Do you know if there is a stable contract in IR to tell whether an argument is in fact a callee-owned memory?

Argument::hasPassPointeeByValueCopyAttr()

Sorry, that's not right. The question you want to answer here is whether the pointer in the caller points to different memory from the pointer in the callee. The only attribute that causes that is byval, and it's very unlikely we'll ever add any others.

inalloca/preallocated memory is part of the callee stack frame, at a low level. But it's actually allocated in the caller, so from an alias-analysis perspective, it doesn't count as a local allocation like byval would.

Sun, Jun 13, 8:58 AM · Restricted Project
lxfind added a comment to D104184: [Coroutine] Properly deal with byval and noalias parameters.

I just realized that this is now getting very similar to D101980, and we are facing the same problem of not always be able to tell whether a param is byval in the midend. Let me continue the discussion on the BasicAA patch.

Sun, Jun 13, 8:54 AM · Restricted Project

Sat, Jun 12

lxfind committed rGfae7debadcea: [CHR] Don't run ControlHeightReduction if any BB has address taken (authored by lxfind).
[CHR] Don't run ControlHeightReduction if any BB has address taken
Sat, Jun 12, 10:30 AM
lxfind closed D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.
Sat, Jun 12, 10:30 AM · Restricted Project
lxfind updated the summary of D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.
Sat, Jun 12, 10:29 AM · Restricted Project
lxfind requested review of D104184: [Coroutine] Properly deal with byval and noalias parameters.
Sat, Jun 12, 10:12 AM · Restricted Project

Fri, Jun 11

lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

Do you know if there is a stable contract in IR to tell whether an argument is in fact a callee-owned memory?

Argument::hasPassPointeeByValueCopyAttr()

Sorry, that's not right. The question you want to answer here is whether the pointer in the caller points to different memory from the pointer in the callee. The only attribute that causes that is byval, and it's very unlikely we'll ever add any others.

inalloca/preallocated memory is part of the callee stack frame, at a low level. But it's actually allocated in the caller, so from an alias-analysis perspective, it doesn't count as a local allocation like byval would.

hmm sounds like hasPassPointeeByValueCopyAttr() is actually what I need. In CoroSplit, when deciding what to put on the coroutine frame, for arguments, I will need to decide whether it's enough to just put the pointer on the frame, or if I need to copy the content of the pointer (much like allocas) to the frame. Sounds like for inalloca and preallocated memory I still want to copy the content to the frame, not just the pointer.

Fri, Jun 11, 5:23 PM · Restricted Project
lxfind added a comment to D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.

Poking around it looks like this should be handled for inlining, not sure why the previous case we ran into wasn't covered by that code below from CallAnalyzer::analyze()

// Disallow inlining a blockaddress with uses other than strictly callbr.
// A blockaddress only has defined behavior for an indirect branch in the
// same function, and we do not currently support inlining indirect
// branches.  But, the inliner may not see an indirect branch that ends up
// being dead code at a particular call site. If the blockaddress escapes
// the function, e.g., via a global variable, inlining may lead to an
// invalid cross-function reference.
// FIXME: pr/39560: continue relaxing this overt restriction.
if (BB->hasAddressTaken())
  for (User *U : BlockAddress::get(&*BB)->users())
    if (!isa<CallBrInst>(*U))
      return InlineResult::failure("blockaddress used outside of callbr");

LGTM, thanks for the fix.

Fri, Jun 11, 5:20 PM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

If you fix the clang code so it isn't generating these extra useless allocas, the problem with byval should become obvious: even without any optimizations, we end up with a use-after-free. corosplit isn't preserving memory that's supposed to be part of the callee frame.

Fri, Jun 11, 8:21 AM · Restricted Project

Thu, Jun 10

lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

This doesn't seem right. A byval argument is essentially a local variable. We should treat it the same way as we would an alloca. If it's live across the first suspend point, it should become part of the coroutine frame.

It will become part of the coroutine frame, by copying it through memcpy. That's actually what's the first memcpy for in the test case.

I don't understand. As far as I can tell, the destination of both memcpys in the testcase are allocas.

OK, so the way coroutine codegen works is to first copy all parameters to local alloca, and then if any of those allocas need to live through coroutine suspension, the alloca will be put on the coroutine frame during the CoroSplit pass.

Thu, Jun 10, 10:37 PM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

This doesn't seem right. A byval argument is essentially a local variable. We should treat it the same way as we would an alloca. If it's live across the first suspend point, it should become part of the coroutine frame.

Thu, Jun 10, 9:38 PM · Restricted Project
lxfind added a comment to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

This doesn't seem right. A byval argument is essentially a local variable. We should treat it the same way as we would an alloca. If it's live across the first suspend point, it should become part of the coroutine frame.

Thu, Jun 10, 9:29 PM · Restricted Project
lxfind updated the diff for D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.

address comment

Thu, Jun 10, 4:45 PM · Restricted Project
lxfind abandoned D102465: [Coroutines] Mark every parameter.
Thu, Jun 10, 1:27 PM · Restricted Project, Restricted Project

Wed, Jun 9

lxfind added a comment to D101510: Do not merge memcpy if the first source is a parameter of coroutine function.

I found a more proper fix in D104007.

Wed, Jun 9, 7:49 PM · Restricted Project
lxfind requested review of D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.
Wed, Jun 9, 7:48 PM · Restricted Project
lxfind abandoned D101510: Do not merge memcpy if the first source is a parameter of coroutine function.
Wed, Jun 9, 7:41 PM · Restricted Project

Tue, Jun 8

lxfind updated the diff for D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.

more test

Tue, Jun 8, 10:02 PM · Restricted Project
lxfind updated the diff for D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.

Only skip regions that contain BBs with address taken

Tue, Jun 8, 10:01 PM · Restricted Project
lxfind updated the diff for D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.

Add test case

Tue, Jun 8, 5:46 PM · Restricted Project
lxfind added a comment to D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.

do all passes that clone BBs have to worry about this?

I think so, as long as the cloned BB is in the same module as the original one, we need to worry about this (there are legit cloning in some tools such as llvm-extract, llvm-reduce..)

Tue, Jun 8, 3:34 PM · Restricted Project
lxfind added inline comments to D103593: [Coroutine] Sink lifetime markers after switch of suspend blocks to avoid disturbing must tail calls.
Tue, Jun 8, 9:27 AM · Restricted Project

Mon, Jun 7

lxfind updated the summary of D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.
Mon, Jun 7, 10:26 PM · Restricted Project
lxfind added reviewers for D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken: yamauchi, wenlei.
Mon, Jun 7, 10:17 PM · Restricted Project
lxfind requested review of D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken.
Mon, Jun 7, 10:16 PM · Restricted Project

Tue, Jun 1

lxfind committed rG41d08541e884: Simplify coro-zero-alloca.ll (authored by lxfind).
Simplify coro-zero-alloca.ll
Tue, Jun 1, 8:13 AM
lxfind closed D103418: Simplify coro-zero-alloca.ll.
Tue, Jun 1, 8:13 AM · Restricted Project

Mon, May 31

lxfind requested review of D103418: Simplify coro-zero-alloca.ll.
Mon, May 31, 9:49 AM · Restricted Project
lxfind added inline comments to D101841: [Coroutines] Do not add alloca to the frame if the size is 0.
Mon, May 31, 9:05 AM · Restricted Project

Tue, May 18

lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

Something like this: D102465. Let me know what you think.

Oh it is tricky. Since we add a new intrinsic use for the alloca and the intrinsic can't be analyzed by other passes. So the alloca we want wouldn't be optimized. The overall ideas looks good. For the details, I would like to emit the intrinsic for the arguments who are passed by value only. I think we could dive into it further.

Tue, May 18, 4:41 PM · Restricted Project

May 14 2021

lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

Something like this: D102465. Let me know what you think.

Oh it is tricky. Since we add a new intrinsic use for the alloca and the intrinsic can't be analyzed by other passes. So the alloca we want wouldn't be optimized. The overall ideas looks good. For the details, I would like to emit the intrinsic for the arguments who are passed by value only. I think we could dive into it further.

May 14 2021, 8:37 AM · Restricted Project

May 13 2021

lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

Something like this: D102465. Let me know what you think.

May 13 2021, 10:07 PM · Restricted Project
lxfind requested review of D102465: [Coroutines] Mark every parameter.
May 13 2021, 10:06 PM · Restricted Project, Restricted Project
lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

It sounds like we still need to touch other passes other coroutine.

No we don't need to. Just need to modify CGCoroutine

May 13 2021, 8:58 PM · Restricted Project
lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

Here is an idea:
we could introduce an intrinsics that doesn't do anything but just server the purpose of telling the compiler to not optimize out a pointer (i.e. indicating maywrite to the pointer).
And in front end, for every copy we create from the parameter, we mark the local copy with that intrinsics. This will make sure that memcpyopt will never optimize it out.

May 13 2021, 11:00 AM · Restricted Project

May 12 2021

lxfind added a comment to D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame.

Sorry for being late in reviewing this patch. I have been out of work for a few days.

May 12 2021, 8:24 AM · Restricted Project

May 6 2021

lxfind added inline comments to D101841: [Coroutines] Do not add alloca to the frame if the size is 0.
May 6 2021, 8:33 AM · Restricted Project

May 4 2021

lxfind committed rGdef86413d4c7: [Coroutines] Do not add alloca to the frame if the size is 0 (authored by lxfind).
[Coroutines] Do not add alloca to the frame if the size is 0
May 4 2021, 12:56 PM
lxfind closed D101841: [Coroutines] Do not add alloca to the frame if the size is 0.
May 4 2021, 12:55 PM · Restricted Project
lxfind added a comment to D101510: Do not merge memcpy if the first source is a parameter of coroutine function.

Since we are already in the space of finding workarounds, when is the memcpy of the byval parameter introduced? Is it compiler generated? If so, could it be marked volatile there? This would limit the coroutines-specific workaround to coroutine code, which move the tech debt burden from generic LLVM code to coroutines code. That would work.

May 4 2021, 12:50 PM · Restricted Project
lxfind updated the diff for D101841: [Coroutines] Do not add alloca to the frame if the size is 0.

Add allocas without cast in test case

May 4 2021, 10:32 AM · Restricted Project
lxfind added reviewers for D101841: [Coroutines] Do not add alloca to the frame if the size is 0: rjmccall, ChuanqiXu.
May 4 2021, 8:48 AM · Restricted Project
lxfind requested review of D101841: [Coroutines] Do not add alloca to the frame if the size is 0.
May 4 2021, 8:48 AM · Restricted Project

May 3 2021

lxfind added inline comments to D76526: Add an algorithm for performing "optimal" layout of a struct..
May 3 2021, 4:47 PM · Restricted Project

Apr 29 2021

lxfind added a comment to D101510: Do not merge memcpy if the first source is a parameter of coroutine function.

Since this is broken anyways, and we are far from branching point, perhaps we should wait until there is a proper fix?

Apr 29 2021, 9:09 AM · Restricted Project

Apr 28 2021

lxfind requested review of D101510: Do not merge memcpy if the first source is a parameter of coroutine function.
Apr 28 2021, 6:48 PM · Restricted Project

Apr 27 2021

lxfind accepted D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

LGTM

Apr 27 2021, 9:16 PM · debug-info, Restricted Project
lxfind added inline comments to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.
Apr 27 2021, 8:40 PM · debug-info, Restricted Project
lxfind added inline comments to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.
Apr 27 2021, 1:32 PM · debug-info, Restricted Project

Apr 23 2021

lxfind added a comment to D100739: [Coroutines] Handle overaligned frame allocation (2).

Sorry for the confusion. I think either overaligned or under-aligned could be used here to describe the problem: either "Handle overaligned frame" or "Fix under-aligned frame". Since c++ spec defines the former but not the later (https://en.cppreference.com/w/cpp/language/object#Alignment), my first intuition was to use the term "overalign". Under-aligned is the undesired outcome that should be fixed (probably too late to handle I assume). Also the overaligned is a static property whereas 'under-aligned" is a runtime property. From the compiler's perspective, I think overaligned should be preferred. With that said, I don't feel strongly about this. I could switch to use "overaligned" if that feels more intuitive.

Apr 23 2021, 7:52 AM · Restricted Project, Restricted Project
lxfind added inline comments to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.
Apr 23 2021, 7:28 AM · debug-info, Restricted Project
lxfind added inline comments to D99179: [RFC] [Coroutines] Enable printing coroutine frame in debugger if program is compiled with -g.
Apr 23 2021, 7:18 AM · debug-info, Restricted Project

Apr 22 2021

lxfind added inline comments to D99179: [RFC] [Coroutines] Enable printing coroutine frame in debugger if program is compiled with -g.
Apr 22 2021, 11:51 AM · debug-info, Restricted Project
lxfind added inline comments to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.
Apr 22 2021, 9:36 AM · debug-info, Restricted Project
lxfind added inline comments to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.
Apr 22 2021, 9:28 AM · debug-info, Restricted Project

Apr 21 2021

lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

Also please add tests to cover more types of variables (allocas, spills..)

Apr 21 2021, 9:57 PM · debug-info, Restricted Project
lxfind added a comment to D100739: [Coroutines] Handle overaligned frame allocation (2).

Thanks for working on this.
I am still having a bit hard time understanding the solution.
A few questions:

  1. I assume this patch is to solve the problem where the promise object is not aligned according to its alignof annotation, right? The title/wording is a bit misleading. Usually "handling XXX" means XXX is a situation/problem that wasn't handle properly before, and it's being handled here. I don't really understand what "handle overaligned frame allocation" means. Isn't frame allocation under-aligned being the problem?
  2. What is the purpose of coro.align intrinsic?
  3. Could you provide some examples of what the IR might look like after this patch? Either that or a more detailed explanation of how this works in the summary.
  4. Do you think it might be cleaner to introduce a new variant of coro.size instead of adding arguments to it? For example, coro.size.aligned(). This way, you can avoid changing any test file for non-switch-lowering test files, but focus on all switch-lowering tests.
  5. Typically, coro.free is used by a comparison with nullptr. This is to enable CoroElide. See: https://llvm.org/docs/Coroutines.html#llvm-coro-free-intrinsic. So I don't think you can load from it directly.
Apr 21 2021, 6:08 PM · Restricted Project, Restricted Project
lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

@lxfind wrote:

Why doesn't replaceUsesOfWith work? Could you double check that replaceUsesOfWith doesn't work for DbgValueInst?

This is by design. Metadata-uses of llvm:Value may not affect code generation, thus they also aren't found by any operation working on llvm::Uses.

Apr 21 2021, 3:42 PM · debug-info, Restricted Project
lxfind added inline comments to D100739: [Coroutines] Handle overaligned frame allocation (2).
Apr 21 2021, 2:38 PM · Restricted Project, Restricted Project
lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

The test is insufficient. I would like to see that we cover dbg.value used on different cases: parameters, allocas, spills.

Apr 21 2021, 2:34 PM · debug-info, Restricted Project

Apr 20 2021

lxfind added inline comments to D100739: [Coroutines] Handle overaligned frame allocation (2).
Apr 20 2021, 5:36 PM · Restricted Project, Restricted Project
lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

Previously all dbg.values would be lost after CoroSplit pass. dbg.value is debug info compiler produced under optimization. This patch wants to remain as many dbg.value as possible while it don't want to change the layout of frame for debug info.

Apr 20 2021, 5:34 PM · debug-info, Restricted Project
lxfind accepted D100614: [Coroutine] Collect CoroBegin if all of terminators are dominated by one coro.destroy.

I see. LGTM. Thanks for fixing. Could you also add comments to the llvm::all_of search with what you just described?

Apr 20 2021, 5:20 PM · Restricted Project
lxfind planned changes to D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.

Plan to add documentation, fix Legacy pass and address comments.

Apr 20 2021, 4:29 PM · Restricted Project, Restricted Project
lxfind reopened D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.
Apr 20 2021, 9:51 AM · Restricted Project, Restricted Project

Apr 19 2021

lxfind added a comment to D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

MLIR is an in-tree project that can be updated.

Apr 19 2021, 11:30 AM · Restricted Project, Restricted Project

Apr 18 2021

lxfind added a comment to D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

This broke MLIR tests.
It seems that MLIR tests depend on CoroEarly to be able to annotate coroutine function properly based on the intrinsics.
Given that, I am now convinced we shouldn't set the attribute in the frontend. Instead we should simply move CoroEarly to before AlwaysInliner.

Apr 18 2021, 5:24 PM · Restricted Project, Restricted Project
lxfind added a reverting change for rGfa6b54c44ab1: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass: rG5faba8793877: Revert "[Coroutines] Set presplit attribute in Clang instead of CoroEarly pass".
Apr 18 2021, 5:23 PM
lxfind committed rG5faba8793877: Revert "[Coroutines] Set presplit attribute in Clang instead of CoroEarly pass" (authored by lxfind).
Revert "[Coroutines] Set presplit attribute in Clang instead of CoroEarly pass"
Apr 18 2021, 5:23 PM
lxfind added a reverting change for D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass: rG5faba8793877: Revert "[Coroutines] Set presplit attribute in Clang instead of CoroEarly pass".
Apr 18 2021, 5:23 PM · Restricted Project, Restricted Project
lxfind committed rGfa6b54c44ab1: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass (authored by lxfind).
[Coroutines] Set presplit attribute in Clang instead of CoroEarly pass
Apr 18 2021, 3:42 PM
lxfind added a reverting change for rG2b50f5a4343f: [Coroutines] Move CoroEarly pass to before AlwaysInliner: rGc0211e8d7d0b: Revert "[Coroutines] Move CoroEarly pass to before AlwaysInliner".
Apr 18 2021, 3:40 PM
lxfind added a reverting change for D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass: rGc0211e8d7d0b: Revert "[Coroutines] Move CoroEarly pass to before AlwaysInliner".
Apr 18 2021, 3:40 PM · Restricted Project, Restricted Project
lxfind committed rGc0211e8d7d0b: Revert "[Coroutines] Move CoroEarly pass to before AlwaysInliner" (authored by lxfind).
Revert "[Coroutines] Move CoroEarly pass to before AlwaysInliner"
Apr 18 2021, 3:39 PM
lxfind added a comment to rG2b50f5a4343f: [Coroutines] Move CoroEarly pass to before AlwaysInliner.

Old patch description?

Apr 18 2021, 3:32 PM
lxfind committed rG2b50f5a4343f: [Coroutines] Move CoroEarly pass to before AlwaysInliner (authored by lxfind).
[Coroutines] Move CoroEarly pass to before AlwaysInliner
Apr 18 2021, 2:58 PM
lxfind closed D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.
Apr 18 2021, 2:58 PM · Restricted Project, Restricted Project
lxfind added a comment to D100614: [Coroutine] Collect CoroBegin if all of terminators are dominated by one coro.destroy.

Does it require that all terminators to be dominated by the same coro.destroy?
Reading the comments in the original code, I think the condition is that for each terminator it's dominated by a coro.destroy, but it doesn't require all terminators to be dominated by the same coro.destroy.
The original code does seem to be buggy, but the fix may not be correct. Perhaps in the next statement, the check on hasEscapePath and ReferencedCoroBegins.count is problematic?

Apr 18 2021, 1:38 PM · Restricted Project
lxfind added inline comments to D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.
Apr 18 2021, 10:43 AM · Restricted Project, Restricted Project
lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

Previously all dbg.values would be lost after CoroSplit pass. dbg.value is debug info compiler produced under optimization. This patch wants to remain as many dbg.value as possible while it don't want to change the layout of frame for debug info.

Apr 18 2021, 10:42 AM · debug-info, Restricted Project

Apr 15 2021

lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

Also, it seems that the newly added test "coro-debug-dbg.values-O2-nouse.ll" passes even without this patch

Apr 15 2021, 4:53 PM · debug-info, Restricted Project
lxfind added a comment to D97673: [RFC] [[Coroutine] [Debug] Salvage dbg.values.

Could you update the description of this patch as well?
It's still not fully clear to me what problem this patch is aiming at resolving.

Apr 15 2021, 4:52 PM · debug-info, Restricted Project
lxfind added a comment to D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.

@ChuanqiXu Thank you for the detailed review! Really appreciate it.
I agree we should create a coroutine benchmark at some point, ideally some realistic production-code driven benchmark. We can work on that in the future. For this patch, it's probably not worth it to hide it behind an option, for two reasons: 1) it would be extremely complicated, 2) most parameters would end up on the frame anyway 3) this patch actually doesn't force parameters to be put on the frame. Before frame creation, all the parameters are put back to allocas, the current alloca analysis and optimization still applies to them. So some parameters may actually end up not put on the frame. So I wouldn't expect this to increase frame size in most cases.

Apr 15 2021, 8:06 AM · Restricted Project, Restricted Project

Apr 14 2021

lxfind added a comment to D76526: Add an algorithm for performing "optimal" layout of a struct..

Out of curiosity, what's the motivating use case for the fixed offset fields in this tool?

Apr 14 2021, 8:17 AM · Restricted Project

Apr 13 2021

lxfind added a comment to D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

I think the setting is in CoroEarly from the beginning is that it is an implementation detail? Clients should only worry about coroutine shape. Maybe we could set noinline in frontends to express the intent and remove it in coroearly/corosplit?

Apr 13 2021, 8:16 PM · Restricted Project, Restricted Project
lxfind updated the diff for D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.

some cleanups

Apr 13 2021, 5:17 PM · Restricted Project, Restricted Project
lxfind updated the summary of D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.
Apr 13 2021, 3:32 PM · Restricted Project, Restricted Project
lxfind added reviewers for D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function: rjmccall, junparser, ChuanqiXu, bruno, wenlei.
Apr 13 2021, 3:31 PM · Restricted Project, Restricted Project
lxfind requested review of D100415: [Coroutines] Split coroutine during CoroEarly into an init and ramp function.
Apr 13 2021, 3:26 PM · Restricted Project, Restricted Project
lxfind updated the diff for D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

Update test

Apr 13 2021, 2:17 PM · Restricted Project, Restricted Project

Apr 12 2021

lxfind retitled D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass from [Coroutines] Move CoroEarly pass to before AlwaysInliner to [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.
Apr 12 2021, 8:47 AM · Restricted Project, Restricted Project
lxfind updated the diff for D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

Set the attributes in Clang instead of CoroEarly

Apr 12 2021, 8:46 AM · Restricted Project, Restricted Project

Apr 11 2021

lxfind added a comment to D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

Ah, if the pass does more than just setting the attribute, then sure, it makes sense to keep it. But I do think we should be requiring the attribute to be added by frontends, since it's really an IR invariant that it's present on all unlowered coroutines.

Apr 11 2021, 10:47 PM · Restricted Project, Restricted Project
lxfind added a comment to D100282: [Coroutines] Set presplit attribute in Clang instead of CoroEarly pass.

Why does this pass even exist? We should just expect the frontend to set the attribute. It's not like frontends don't have to otherwise know that they're emitting a coroutine; a ton of things about the expected entire IR pattern are different.

Apr 11 2021, 10:30 PM · Restricted Project, Restricted Project