Page MenuHomePhabricator

luna (Mingming Liu)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 14 2021, 10:30 PM (14 w, 2 d)

Recent Activity

Wed, Jan 19

luna closed D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

This is submitted in https://github.com/llvm/llvm-project/commit/e95ad93e6ef874ad208028c18b4cb4890320f25c

Wed, Jan 19, 6:21 PM · Restricted Project
luna committed rGe95ad93e6ef8: [llvm-dis] Add an option `dump-thinlto-index-only` in llvm-dis to read ThinLTO… (authored by luna).
[llvm-dis] Add an option `dump-thinlto-index-only` in llvm-dis to read ThinLTO…
Wed, Jan 19, 6:11 PM
luna added a comment to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

pre-merge tests all passed. Going to submit the patch.

Wed, Jan 19, 6:07 PM · Restricted Project
luna added inline comments to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Wed, Jan 19, 2:24 PM · Restricted Project
luna added inline comments to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Wed, Jan 19, 2:23 PM · Restricted Project
luna updated the diff for D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

Revise based on feedback.

Wed, Jan 19, 2:23 PM · Restricted Project
luna retitled D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly. from [llvm-dis] Add an option `dump-thinlto-index-only` in llvm-dis to read ThinLTO minimized code only. to [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to read ThinLTO minimized code only..
Wed, Jan 19, 10:21 AM · Restricted Project
luna updated the diff for D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

Remove outdated verbose comment in BitcodeReader::parseGlobalVarRecord since there is a comment to cover more types of records.

Wed, Jan 19, 10:14 AM · Restricted Project
luna added inline comments to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Wed, Jan 19, 10:13 AM · Restricted Project
luna updated the diff for D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

Revise based on feedback.

Wed, Jan 19, 10:13 AM · Restricted Project

Tue, Jan 18

luna committed rG76b74236c7f9: Update bitcode format doc to mention that a multi-module bitcode file is (authored by luna).
Update bitcode format doc to mention that a multi-module bitcode file is
Tue, Jan 18, 5:51 PM
luna closed D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block.
Tue, Jan 18, 5:50 PM · Restricted Project
luna added a comment to D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block.

lgtm on the documentation change but that should be submitted separately as it is unrelated to the code fix.
The other change lgtm but if it is feasible to add a test that would be ideal.

Tue, Jan 18, 5:32 PM · Restricted Project
luna updated the diff for D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block.

Keep the documentation change and put bitcode reader change to https://reviews.llvm.org/D117630 (which is still a draft).

Tue, Jan 18, 5:27 PM · Restricted Project
luna updated the diff for D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..

Add a flag in llvm-dis to print index, and it's up to command runner to decide if the input is a fit (e.g., a ThinLTO bitcode).

Tue, Jan 18, 5:10 PM · Restricted Project

Thu, Jan 13

luna added inline comments to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Thu, Jan 13, 4:10 PM · Restricted Project
luna added inline comments to D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Thu, Jan 13, 2:38 PM · Restricted Project
luna requested review of D117244: [llvm-dis] Add an option `print-thinlto-index-only` in llvm-dis to print index in LLVM assembly..
Thu, Jan 13, 12:52 PM · Restricted Project
luna retitled D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block from Call takeError if MaybeVBR doesn't have a value. to [Bitcode] Call takeError if MaybeVBR doesn't have a value, and update bitcode doc on module block.
Thu, Jan 13, 10:00 AM · Restricted Project
luna updated the diff for D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block.

Update bitcode format to mention multi-module bitcode.

Thu, Jan 13, 9:58 AM · Restricted Project

Wed, Jan 12

luna abandoned D115914: [InstCombine] Fold two PHI operands of `or` conditionally..

actually diff of abandoned revisions are stored somewhere and seems to be available for download. this is good so no need to maintain a local copy.

Wed, Jan 12, 5:46 PM · Restricted Project
luna abandoned D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..
Wed, Jan 12, 5:45 PM · Restricted Project
luna added a comment to D115914: [InstCombine] Fold two PHI operands of `or` conditionally..

thanks everyone for the feedback!

carrot@ had a fix for another issue (in https://reviews.llvm.org/D116058) that has overlap with this one, but covering more cases like https://godbolt.org/z/or7W1b7eE and https://godbolt.org/z/MqTh5Te9c

I'm going to hold this for a while; hopefully after https://reviews.llvm.org/D116058 is in, this patch is not needed.

I don't think D116058 is viable (and I'll comment there too).
This patch seems ok, but it's both too restrictive (only works with 'or') and potentially more costly than necessary (at least as a first step, we can check for constants instead of trying to simplify generally and fix the motivating tests). I put up an alternate patch: D117110 .

Wed, Jan 12, 5:44 PM · Restricted Project
luna added inline comments to D117110: [InstCombine] try to fold binop with phi operands.
Wed, Jan 12, 5:38 PM · Restricted Project

Tue, Jan 11

luna published D117067: [Bitcode] Mention that a multi-module bitcode is valid, each module has exactly one MODULE_BLOCK block for review.
Tue, Jan 11, 4:58 PM · Restricted Project

Mon, Jan 10

luna added a comment to D115914: [InstCombine] Fold two PHI operands of `or` conditionally..

thanks everyone for the feedback!

Mon, Jan 10, 4:08 PM · Restricted Project

Dec 21 2021

luna committed rG9c49f8d70592: [LTO][WPD] Ignore unreachable function by analyzing IR. (authored by luna).
[LTO][WPD] Ignore unreachable function by analyzing IR.
Dec 21 2021, 10:15 AM
luna closed D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..
Dec 21 2021, 10:15 AM · Restricted Project
luna added a comment to D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..

thanks!

Dec 21 2021, 9:35 AM · Restricted Project
luna updated the diff for D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..

Remove comments on function declarations, as a combined index may contain entries for func declarations.

Dec 21 2021, 9:35 AM · Restricted Project
luna committed rG55c71c9eac9b: Simplify WPD test case for hybrid LTO and thinTLO. (authored by luna).
Simplify WPD test case for hybrid LTO and thinTLO.
Dec 21 2021, 9:28 AM
luna closed D116071: Simplify WPD test case for hybrid LTO and thinTLO..
Dec 21 2021, 9:27 AM · Restricted Project
luna added a comment to D116071: Simplify WPD test case for hybrid LTO and thinTLO..

thanks for review!

Dec 21 2021, 9:22 AM · Restricted Project
luna updated the diff for D116071: Simplify WPD test case for hybrid LTO and thinTLO..

Remove ".virtual" type metadata.

Dec 21 2021, 9:21 AM · Restricted Project

Dec 20 2021

luna updated the diff for D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..

remove No newline at end of file by using a different editor

Dec 20 2021, 7:14 PM · Restricted Project
luna updated the diff for D116071: Simplify WPD test case for hybrid LTO and thinTLO..

resolve No newline at end of file by using a different editor

Dec 20 2021, 7:11 PM · Restricted Project
luna published D116071: Simplify WPD test case for hybrid LTO and thinTLO. for review.

Hi Teresa,

I'm taking the liberty to create a separate revision for clean-ups.
Dec 20 2021, 7:06 PM · Restricted Project
luna added a comment to D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..

thanks for review!

Dec 20 2021, 4:57 PM · Restricted Project
luna updated the diff for D116056: [LTO][WPD] Ignore unreachable function by analyzing IR..

Save one index lookup if function def is present for IR analysis. Also simplify test case.

Dec 20 2021, 4:55 PM · Restricted Project
luna published D116056: [LTO][WPD] Ignore unreachable function by analyzing IR. for review.
Dec 20 2021, 3:04 PM · Restricted Project

Dec 16 2021

luna added a comment to D115914: [InstCombine] Fold two PHI operands of `or` conditionally..

This revision handles the simple case (as shown in llvm/test/Transforms/InstCombine/fold-phi-of-binary-op.ll).

Dec 16 2021, 4:40 PM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

thanks everyone for the feedback!

Dec 16 2021, 4:35 PM · Restricted Project
luna published D115914: [InstCombine] Fold two PHI operands of `or` conditionally. for review.
Dec 16 2021, 4:34 PM · Restricted Project

Dec 15 2021

luna committed rG4ab5527c15f0: [ThinLTO] Ignore unreachable virtual functions in WPD in thin LTO. (authored by luna).
[ThinLTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 15 2021, 6:27 PM
luna closed D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 15 2021, 6:27 PM · Restricted Project, Restricted Project
luna added a comment to D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Simplify test case by using -O3 to generate IR.

Dec 15 2021, 5:07 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Simplify test case by using -O3 to generate IR.

Dec 15 2021, 4:55 PM · Restricted Project, Restricted Project
luna accepted D115780: [LTO][WPD] Simplify mustBeUnreachableFunction and test after D115492.
Dec 15 2021, 10:44 AM · Restricted Project
luna added a comment to D115780: [LTO][WPD] Simplify mustBeUnreachableFunction and test after D115492.

thanks for the simplification!

Dec 15 2021, 10:06 AM · Restricted Project

Dec 14 2021

luna added a comment to D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

thanks for the inputs!

Dec 14 2021, 8:02 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Simplify filecheck by re-using one prefix to test the unreachable bit.

Dec 14 2021, 8:01 PM · Restricted Project, Restricted Project
luna added inline comments to D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 14 2021, 6:23 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Simplify test by sharing one pattern across two filecheck lines.

Dec 14 2021, 6:23 PM · Restricted Project, Restricted Project
luna added a comment to D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

thanks for review!

Dec 14 2021, 6:17 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Simplify test by using non-DAG prefix (for one pattern), and avoid capturing values since they are not used.

Dec 14 2021, 6:13 PM · Restricted Project, Restricted Project
luna added a comment to D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

thanks for review!

Dec 14 2021, 5:59 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Change test IR by removing irrelevant lines and using one prefix per FileCheck.

Dec 14 2021, 5:54 PM · Restricted Project, Restricted Project
luna updated the summary of D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 14 2021, 2:39 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Rebase to main

Dec 14 2021, 2:37 PM · Restricted Project, Restricted Project
luna added a reviewer for D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations.: adriantong1024.
Dec 14 2021, 2:28 PM · Restricted Project
luna committed rG09a704c5efba: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO. (authored by luna).
[LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.
Dec 14 2021, 12:18 PM
luna closed D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.
Dec 14 2021, 12:18 PM · Restricted Project, Restricted Project
luna added a comment to D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

lgtm after adding a description to test as noted below.

Dec 14 2021, 9:48 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Describe what the test case devirt_hybrid_after_filtering_unreachable.ll is for.

Dec 14 2021, 9:48 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Revise based on comments.

Dec 14 2021, 8:58 AM · Restricted Project, Restricted Project
luna added inline comments to D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.
Dec 14 2021, 8:58 AM · Restricted Project, Restricted Project

Dec 13 2021

luna retitled D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO from [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO to [LTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 13 2021, 12:20 PM · Restricted Project, Restricted Project
luna updated the diff for D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.

Add unit test for thinlto.

Dec 13 2021, 12:04 PM · Restricted Project, Restricted Project
luna requested review of D115648: [LTO] Ignore unreachable virtual functions in WPD in thin LTO.
Dec 13 2021, 9:41 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Use type auto for GUID to fix a compile error.

Dec 13 2021, 9:28 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Use GUID computed with exported function name as a fallback to look up index when there isn't an entry for current function GUID.

Dec 13 2021, 9:20 AM · Restricted Project, Restricted Project

Dec 10 2021

luna added a reviewer for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO: tejohnson.
Dec 10 2021, 10:34 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Remove verbose attributes from test case

Dec 10 2021, 10:24 AM · Restricted Project, Restricted Project
luna updated the diff for D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

Revert unit test that shouldn't be affected.

Dec 10 2021, 12:21 AM · Restricted Project, Restricted Project

Dec 9 2021

luna requested review of D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.
Dec 9 2021, 11:33 PM · Restricted Project, Restricted Project

Dec 8 2021

luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

Driven by the compile-time feedback, another thing for me to consider, (probably after a preliminary convergence on the pass to add analysis info or do the transform), is to prune the existing solution so it's faster on the benchmark.

Your current method is

1 collect all accesses to an alloca object, mark the access type
2 check the aggregated access types, if there is only <store constant> type, mark the object as unsplittable.

I think in step1, if the access type is not <store constant>, you can bail out early, then for most splittable objects the check can be finished quickly.

Dec 8 2021, 4:10 PM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

thanks for the feedback!

Dec 8 2021, 4:06 PM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

The bad code pattern generated is probably not general enough to be useful to introduce a cleanup pass or to enhance existing pass to do so -- it will probably just shift the complexity from one pass to another. Fixing this at the source (SROA) is reasonable (unlike other canonicalization pass, this code pattern from SROA actually makes IR much worse)

Who defines what is/isn't reasonable? :)

As i see it, the input IR may or may not already have such bad patterns that are similar to the bad patterns you are trying to avoid producing here.
Trying to avoid producing it has compile time cost: https://llvm-compile-time-tracker.com/compare.php?from=0850655da69a700b7def4fe8d9a44d1c8d55877c&to=8a4304c8f4253fb1944e5e5988a24285a14181c4&stat=instructions
So, you've paid for avoiding producing more bad patterns, but you are still left with the ones that were already there.

Alternatively, instead of paying for trying not to introduce bad patterns, you could pay for trying to improve all of the patterns afterwards, regardless of their source.
Then, you still end up paying, but end up with not just the SROA patterns improved.

This is a very standard logic behind IR changes - if something doesn't understand the pattern, generally don't try to workaround it elsewhere, just fix the missing piece.

I agree with most of what you said as a general principle, while analysis should be done case by case :)

The assumption is that the producer (SROA) is pretty much the only creator of the pattern (excluding manually written IR), thus cleaning it up downstream does not really help in sharing. The compile time cost is also shifted. Imagine another hypothetical scenario: if we there are N different unique bad patterns that can be handled by one single analysis pass in the source pass, we may need to have N different downstream pass changes to handle them resulting in more waste.

Having said that, suggestions on which downstream pass to handle this is useful. IIRC Mingming considered CodegenPrepare where some taildup can be done to handle tailcalls ...

thanks for the discussions and insight everyone!

The compile time link is helpful. Is there a pointer or rule-of-thumb to evaluate cost vs benefit?

  • Ask since the current analysis is inlined in an existing instruction walker. Adding a separate transformation (as opposed to choose a good existing one to piggyback on) would likely increase the cost (with the same effect).

It seems the other option to consider is have a separate pass to transform bad patterns, or reuse an existing pass like CodeGenPrepare.

It'd be helpful to know a pass that I should probably look more into, to achieve the original optimization goal here.

Driven by the compile-time feedback, another thing for me to consider, (probably after a preliminary convergence on the pass to add analysis info or do the transform), is to prune the existing solution so it's faster on the benchmark.

Dec 8 2021, 10:26 AM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

The bad code pattern generated is probably not general enough to be useful to introduce a cleanup pass or to enhance existing pass to do so -- it will probably just shift the complexity from one pass to another. Fixing this at the source (SROA) is reasonable (unlike other canonicalization pass, this code pattern from SROA actually makes IR much worse)

Who defines what is/isn't reasonable? :)

As i see it, the input IR may or may not already have such bad patterns that are similar to the bad patterns you are trying to avoid producing here.
Trying to avoid producing it has compile time cost: https://llvm-compile-time-tracker.com/compare.php?from=0850655da69a700b7def4fe8d9a44d1c8d55877c&to=8a4304c8f4253fb1944e5e5988a24285a14181c4&stat=instructions
So, you've paid for avoiding producing more bad patterns, but you are still left with the ones that were already there.

Alternatively, instead of paying for trying not to introduce bad patterns, you could pay for trying to improve all of the patterns afterwards, regardless of their source.
Then, you still end up paying, but end up with not just the SROA patterns improved.

This is a very standard logic behind IR changes - if something doesn't understand the pattern, generally don't try to workaround it elsewhere, just fix the missing piece.

I agree with most of what you said as a general principle, while analysis should be done case by case :)

The assumption is that the producer (SROA) is pretty much the only creator of the pattern (excluding manually written IR), thus cleaning it up downstream does not really help in sharing. The compile time cost is also shifted. Imagine another hypothetical scenario: if we there are N different unique bad patterns that can be handled by one single analysis pass in the source pass, we may need to have N different downstream pass changes to handle them resulting in more waste.

Having said that, suggestions on which downstream pass to handle this is useful. IIRC Mingming considered CodegenPrepare where some taildup can be done to handle tailcalls ...

thanks for the discussions and insight everyone!

The compile time link is helpful. Is there a pointer or rule-of-thumb to evaluate cost vs benefit?

  • Ask since the current analysis is inlined in an existing instruction walker. Adding a separate transformation (as opposed to choose a good existing one to piggyback on) would likely increase the cost (with the same effect).

It seems the other option to consider is have a separate pass to transform bad patterns, or reuse an existing pass like CodeGenPrepare.

It'd be helpful to know a pass that I should probably look more into, to achieve the original optimization goal here.

Dec 8 2021, 9:40 AM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

The bad code pattern generated is probably not general enough to be useful to introduce a cleanup pass or to enhance existing pass to do so -- it will probably just shift the complexity from one pass to another. Fixing this at the source (SROA) is reasonable (unlike other canonicalization pass, this code pattern from SROA actually makes IR much worse)

Who defines what is/isn't reasonable? :)

As i see it, the input IR may or may not already have such bad patterns that are similar to the bad patterns you are trying to avoid producing here.
Trying to avoid producing it has compile time cost: https://llvm-compile-time-tracker.com/compare.php?from=0850655da69a700b7def4fe8d9a44d1c8d55877c&to=8a4304c8f4253fb1944e5e5988a24285a14181c4&stat=instructions
So, you've paid for avoiding producing more bad patterns, but you are still left with the ones that were already there.

Alternatively, instead of paying for trying not to introduce bad patterns, you could pay for trying to improve all of the patterns afterwards, regardless of their source.
Then, you still end up paying, but end up with not just the SROA patterns improved.

This is a very standard logic behind IR changes - if something doesn't understand the pattern, generally don't try to workaround it elsewhere, just fix the missing piece.

I agree with most of what you said as a general principle, while analysis should be done case by case :)

The assumption is that the producer (SROA) is pretty much the only creator of the pattern (excluding manually written IR), thus cleaning it up downstream does not really help in sharing. The compile time cost is also shifted. Imagine another hypothetical scenario: if we there are N different unique bad patterns that can be handled by one single analysis pass in the source pass, we may need to have N different downstream pass changes to handle them resulting in more waste.

Having said that, suggestions on which downstream pass to handle this is useful. IIRC Mingming considered CodegenPrepare where some taildup can be done to handle tailcalls ...

Dec 8 2021, 9:16 AM · Restricted Project

Dec 7 2021

luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

Can the issues instead be viewed as missed transformations that should be implemented instead of trying to prevent creating those "bad" patterns?

Dec 7 2021, 10:52 AM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

A gentle ping. Please let me know if there are any feedback, thanks!

Dec 7 2021, 10:19 AM · Restricted Project

Dec 2 2021

luna updated the diff for D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

Update revision after git rebase

Dec 2 2021, 4:54 PM · Restricted Project
luna committed rG603a39b670c7: Run update_test_checks.py on test cases. (authored by luna).
Run update_test_checks.py on test cases.
Dec 2 2021, 4:27 PM
luna closed D115006: Run update_test_checks.py on test cases..
Dec 2 2021, 4:26 PM · Restricted Project
luna added inline comments to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..
Dec 2 2021, 4:23 PM · Restricted Project
luna requested review of D115006: Run update_test_checks.py on test cases..
Dec 2 2021, 4:22 PM · Restricted Project
luna added inline comments to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..
Dec 2 2021, 2:41 PM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

I'm not familiar with the term "coalesce instructions", and it doesn't appear anywhere in SROA.cpp, could you explain that in the description?

Dec 2 2021, 2:29 PM · Restricted Project
luna updated the diff for D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

Clean up CHECK that were manually added previously, but not needed when we use update_test_checks.py.

Dec 2 2021, 2:22 PM · Restricted Project
luna updated the diff for D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

Use update_test_checks.py to update test/Transforms/SROA/alloca-struct.ll.

  1. In this revision, the opt used is built with this patch.
  2. Test case test_struct_of_int_char and test_one_field_has_runtime_value should remain unchanged.
  3. Diff of test case test_struct_of_two_int is shown in https://gist.github.com/minglotus-6/a05ac0300d8ea8204ec9eed409951b25/revisions
Dec 2 2021, 2:20 PM · Restricted Project
luna abandoned D114764: Use `thin` that starts with lowercase letter. - `Thin` gives an error when following https://clang.llvm.org/docs/ThinLTO.html#clang-bootstrap, and `thin` works..
Dec 2 2021, 1:31 PM · Restricted Project

Dec 1 2021

luna added inline comments to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..
Dec 1 2021, 10:36 AM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

That's a lot of complexity. It sounds like we are missing some cleanup transforms in some other passes?
Can you please post a standalone example of the "bad" codegen (via a godbolt link) that you are trying to avoid?

To compare the LLVM and GCC codegen, tail call is generated in GCC but not LLVM.

test_struct_of_two_int (from llvm/test/Transforms/SROA/alloca-struct.ll) shows the diff in IR level before and after this change, and run clang with this patch (clang -S -O3 file.cpp) would generate a tail call.

Dec 1 2021, 9:28 AM · Restricted Project
luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

That's a lot of complexity. It sounds like we are missing some cleanup transforms in some other passes?
Can you please post a standalone example of the "bad" codegen (via a godbolt link) that you are trying to avoid?

Dec 1 2021, 9:23 AM · Restricted Project

Nov 30 2021

luna added a comment to D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations..

I suggest simplify the title to : "Improve SROA to prevent generating redundant coalescing operations'.

Nov 30 2021, 5:00 PM · Restricted Project
luna retitled D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations. from [SROA] For a type of alloca access, skip scalarization in SROA pass; the goal is to save useless operations to coalesce values. to [SROA] Improve SROA to prevent generating redundant coalescing operations..
Nov 30 2021, 4:59 PM · Restricted Project
luna published D114832: [SROA] Improve SROA to prevent generating redundant coalescing operations. for review.
Nov 30 2021, 4:55 PM · Restricted Project

Nov 29 2021

luna added a comment to D114764: Use `thin` that starts with lowercase letter. - `Thin` gives an error when following https://clang.llvm.org/docs/ThinLTO.html#clang-bootstrap, and `thin` works..

There are some other docs that also use "Thin" (and "Full", etc). I see my own script uses "THIN" for this cmake variable. Looks like we convert to uppercase so I wouldn't think it should matter:
See llvm/cmake/modules/HandleLLVMOptions.cmake:30

Can you clarify what problem you are encountering? I'm not sure I understand the reference to WholeProgramDevirt.cpp in the title.

Nov 29 2021, 6:37 PM · Restricted Project
luna retitled D114764: Use `thin` that starts with lowercase letter. - `Thin` gives an error when following https://clang.llvm.org/docs/ThinLTO.html#clang-bootstrap, and `thin` works. from Use `thin` that starts with lowercase letter. - `Thin` gives an error when following lib/Transforms/IPO/WholeProgramDevirt.cpp, and `thin` works. to Use `thin` that starts with lowercase letter. - `Thin` gives an error when following https://clang.llvm.org/docs/ThinLTO.html#clang-bootstrap, and `thin` works..
Nov 29 2021, 6:24 PM · Restricted Project