If the extracted region has multiple exported data flows toward the same BB which is not included in the region, correct resotre instructions and PHI nodes won't be generated inside the exitStub. The solution is simply put the restore instructions right after the definition of output values instead of putting in exitStub.
Unittest for this bug is included
Details
Diff Detail
Event Timeline
Please don't update it manually.
Pretty much every manual update LLVM does has been proven incorrect over time.
Please just express the added/removed edges if you have to.
If you are cutting out a region, this should not be difficult.
I have to agree with Danny, I'm not sure this version is correct. It should be fairly easy to use the batch updater here.
If we discover that doing incremental update makes the code too slow, that it's also great, as I still haven't come up a good benchmark to tell me what needs more optimization.
Nit: please run clang-format on your changes.
lib/Transforms/Utils/CodeExtractor.cpp | ||
---|---|---|
473 | Does this handle the self-loop case? | |
480 | In general, we prefer to update DFS numbers lazily and it's better to just invalidate them. |
lib/Transforms/Utils/CodeExtractor.cpp | ||
---|---|---|
771 | You can use auto here, as the type is obvious looking at the right hand side. |
It turn out that the DomTree updating issue has actually been fixed in D32308
The unittest also pass after I applying that change
Sorry I didn't work incrementally on master branch at first place
Can you revert the unrelated formatting changes? Otherwise reviewing this is a bit hard.
I think the point was to only format your changes, not the surrounding code. You can use the clang-format-diff.py script to to that.
lib/Transforms/Utils/CodeExtractor.cpp | ||
---|---|---|
791 | Why is it the case that incrementing OAI works here and gets to OutputArgEnd? Same with the GEP::Create, why is passing the OAI pointer there valid if it doesn't get incremented and you use outputs[i] the same time? This is not clear to me, could you consider adding a comment? | |
unittests/Transforms/Utils/CodeExtractor.cpp | ||
57 | nit: s/require/requires | |
68 | Why is FALSE expected here? |
lib/Transforms/Utils/CodeExtractor.cpp | ||
---|---|---|
791 | The original code didn't check the OutputArgEnd either, however I add an assertion anyway. OAI iterator shouldn't be increased in each iteration if AggregateArgs is true. Since under the configuration of using aggregate argument, there would be only one struct argument that accommodate all of the output values in struct fields, and OAI should always point to that struct argument. The code comment in the original code seems to be not related to the aggregate argument condition, but I add few comment regarding this concern anyway | |
unittests/Transforms/Utils/CodeExtractor.cpp | ||
68 | verifyFunction would return false if no error |
lib/Transforms/Utils/CodeExtractor.cpp | ||
---|---|---|
745–746 | nit: s/reference/reference. | |
770 | nit: s/value/value. | |
782 | nit: maybe s/amount/number? | |
792 | Maybe s/increase/increment or even s/increase/advance? | |
793 | nit: s/point/points | |
unittests/Transforms/Utils/CodeExtractor.cpp | ||
59 | nit: s/ones/ones. | |
68 | Maybe that's obvious for people more familiar with this part of the codebase, but I'd appreciate a comment explaining that here :) |
@chandlerc @kuhar
I'm not pretty familiar the procedure yet, could someone help me commit the patch or merge it?
Thanks
If you have commit access, you can go ahead and submit the patch. Otherwise, I can submit it for you.
Please take a look here: Obtaining Commit Access.
Since this is my first time committing a patch, I guess I don't have enough record for being granted the commit access
Please submit this changed for me, thanks!
With your patch, FindPhiPredForUseInBlock becomes unused and it causes the following warning to be emitted:
llvm/lib/Transforms/Utils/CodeExtractor.cpp:657:20: warning: unused function 'FindPhiPredForUseInBlock' [-Wunused-function] static BasicBlock* FindPhiPredForUseInBlock(Value* Used, BasicBlock* BB) {
And that would make many buildbots very grumpy :)
I think that the function should be now deleted, as it has no users.
Does this handle the self-loop case?