Page MenuHomePhabricator
Feed Advanced Search

Jun 20 2022

duck-37 updated the diff for D125072: [MachineOutliner] Make getOutliningType partially target-independent.

Rebase.

Jun 20 2022, 8:15 PM · Restricted Project, Restricted Project

May 21 2022

duck-37 updated the diff for D125072: [MachineOutliner] Make getOutliningType partially target-independent.

Rebase.

May 21 2022, 11:50 AM · Restricted Project, Restricted Project

May 7 2022

duck-37 updated the diff for D125072: [MachineOutliner] Make getOutliningType partially target-independent.

Rebase, update a few comments.

May 7 2022, 12:39 PM · Restricted Project, Restricted Project

May 6 2022

duck-37 updated the summary of D125072: [MachineOutliner] Make getOutliningType partially target-independent.
May 6 2022, 9:23 AM · Restricted Project, Restricted Project
duck-37 updated the summary of D125072: [MachineOutliner] Make getOutliningType partially target-independent.
May 6 2022, 9:21 AM · Restricted Project, Restricted Project
duck-37 updated the diff for D125072: [MachineOutliner] Make getOutliningType partially target-independent.

Rebase and add assertions for other operands that shouldn't exist at this point.

May 6 2022, 9:20 AM · Restricted Project, Restricted Project
duck-37 added a comment to D122635: [RISCV] Filter out instructions which contain unsafe things when outlining.

D125072 does the favor.

May 6 2022, 7:25 AM · Restricted Project, Restricted Project

May 5 2022

duck-37 updated the diff for D125072: [MachineOutliner] Make getOutliningType partially target-independent.

Comment clarification and typo fix.

May 5 2022, 8:50 PM · Restricted Project, Restricted Project
duck-37 removed a reviewer for D125072: [MachineOutliner] Make getOutliningType partially target-independent: jpaquette.
May 5 2022, 8:42 PM · Restricted Project, Restricted Project
duck-37 requested review of D125072: [MachineOutliner] Make getOutliningType partially target-independent.
May 5 2022, 8:39 PM · Restricted Project, Restricted Project

Apr 30 2022

duck-37 added a comment to D124707: [AArch64] Make sure XRay pseudo-instruction sizes are reported correctly.
Apr 30 2022, 9:53 AM · Restricted Project, Restricted Project

Apr 29 2022

duck-37 planned changes to D124707: [AArch64] Make sure XRay pseudo-instruction sizes are reported correctly.

Okay, taking this off the review queue until I take a look at the other bug incidentally exposed by fixing this one; the MachineOutliner doesn't properly adjust attributes of new outlined functions with XRay instrumentation opcodes. (should it even run on those at all?)
As such, what happens is that this check doesn't pass, meaning CurrentFnBegin isn't set, meaning that an assertion failure is thrown when the code generator tries to use it as a symbol when emitting the XRay instrumentation table.
The reason this testcase didn't fail before is because AArch64InstrInfo::getOutliningCandidateInfo uses the sizes of instructions as part of the outlining heuristic. When the pseudo-opcode sizes were fixed, the heuristic decided it was profitable to outline an XRay pseudo-instruction, triggering the bug.

Apr 29 2022, 7:05 PM · Restricted Project, Restricted Project
duck-37 updated the diff for D124707: [AArch64] Make sure XRay pseudo-instruction sizes are reported correctly.

Add newline to end of test case

Apr 29 2022, 5:54 PM · Restricted Project, Restricted Project
duck-37 requested review of D124707: [AArch64] Make sure XRay pseudo-instruction sizes are reported correctly.
Apr 29 2022, 5:44 PM · Restricted Project, Restricted Project

Oct 14 2021

duck-37 abandoned D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Note: abandoning this due to concerns mentioned above. Will run some more testing with this entire block removed.

Oct 14 2021, 12:36 PM · Restricted Project

Oct 13 2021

duck-37 added inline comments to D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..
Oct 13 2021, 6:40 PM · Restricted Project
duck-37 updated the diff for D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..

Make clang-format happy.

Oct 13 2021, 9:02 AM · Restricted Project
duck-37 added a comment to D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Thanks, that sounds like a really good improvement!

I just wanted to quickly check your testing strategy. Problem is function specialisation isn't enabled by default, so isn't covered by the upstream buildbots and tests. I shot myself in the foot recently by introducing a performance regression that I noticed later and then took me more time to fix (I am tracking performance now with function specialisation enabled).
I usually hack the compiler in Transforms/IPO/PassManagerBuilder.cpp:175 as I find that easier to pass flags in different build systems and change cl::init(false) into true, and then run some code: a stage2 build would be good, and the llvm test suite too, these would be the minimum and function specialisation should trigger in both. And sorry if you're doing this already, but just wanted to check. If you can it would be good if you run SPEC too and see that the MCF score is unaffected (with LTO that is, it should trigger on MCF so if it doesn't anymore we have a problem :) ).
But I think I can quickly run SPEC today, so will do that and report back here.

My testing "strategy" at the moment is essentially just throwing this insane LTO module at it and seeing whether it breaks or not. Problem is I have a lot of weird patches on the pass at the moment so it's somewhat difficult to isolate individual things to upstream. Will try running tests later.

That's a good start! :-) But yeah, please try to test more (the llvm regr tests are a no brainer), but like I said at least the llvm test suite and a stage2 build would be good.
I've run SPEC and that seems unaffected so is good.

I haven't looked much into this change itself to be honest (thanks @ChuanqiXu ), but the different iterations of this patch makes me wonder if some of this could or should have been caught by regression tests. Are we missing some coverage there?

Oct 13 2021, 8:17 AM · Restricted Project
duck-37 updated the diff for D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..

Fix faulty assertion.

Oct 13 2021, 6:31 AM · Restricted Project
duck-37 added a comment to D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..

Oh wait, sorry, regressions test fail, they trigger this assert. We should assert that CS.getCalledFunction() == F? Also, in asserts it is custom to add a message/diagnostic, so that will be:

assert(CS.getCalledFunction() == F && "function and callee should be same");

or something along those lines.

Oct 13 2021, 6:29 AM · Restricted Project
duck-37 updated the diff for D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..

Change from if statement to assert.

Oct 13 2021, 5:08 AM · Restricted Project
duck-37 added a comment to D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..

Thanks for contributing to function specialisation by the way, I have also noticed your other patch that I will look at soon. I am happy to commit things on your behalf like the previous one, but you have a few patches in the pipeline and if you plan to do more llvm work, you could consider requesting an account so that you can commit it yourself. I believe the process to get commit rights isn't that difficult and should be quick. But up to you, like I said, am happy to commit things on your behalf.

Oct 13 2021, 5:07 AM · Restricted Project
duck-37 updated the diff for D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Make sure replaceAllUsesWith is also removed.

Oct 13 2021, 5:01 AM · Restricted Project
duck-37 added inline comments to D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..
Oct 13 2021, 5:00 AM · Restricted Project
duck-37 added a comment to D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Thanks, that sounds like a really good improvement!

I just wanted to quickly check your testing strategy. Problem is function specialisation isn't enabled by default, so isn't covered by the upstream buildbots and tests. I shot myself in the foot recently by introducing a performance regression that I noticed later and then took me more time to fix (I am tracking performance now with function specialisation enabled).
I usually hack the compiler in Transforms/IPO/PassManagerBuilder.cpp:175 as I find that easier to pass flags in different build systems and change cl::init(false) into true, and then run some code: a stage2 build would be good, and the llvm test suite too, these would be the minimum and function specialisation should trigger in both. And sorry if you're doing this already, but just wanted to check. If you can it would be good if you run SPEC too and see that the MCF score is unaffected (with LTO that is, it should trigger on MCF so if it doesn't anymore we have a problem :) ).
But I think I can quickly run SPEC today, so will do that and report back here.

Oct 13 2021, 4:59 AM · Restricted Project
duck-37 added inline comments to D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..
Oct 13 2021, 4:56 AM · Restricted Project
duck-37 updated the diff for D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Make sure not to diff off of a local branch instead of main.

Oct 13 2021, 4:53 AM · Restricted Project
duck-37 updated the diff for D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..

Visit with SCCPSolver after replacing users.

Oct 13 2021, 4:49 AM · Restricted Project
duck-37 added inline comments to D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..
Oct 13 2021, 4:43 AM · Restricted Project

Oct 12 2021

duck-37 added inline comments to D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..
Oct 12 2021, 11:36 AM · Restricted Project
duck-37 requested review of D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use..
Oct 12 2021, 10:42 AM · Restricted Project
duck-37 requested review of D111660: [FuncSpec] Make sure function is actually the callee before trying to specialize..
Oct 12 2021, 10:37 AM · Restricted Project

Oct 5 2021

duck-37 added a comment to D111112: [SCCPSolver] Fix use-after-free in markArgInFuncSpecialization..

No worries, and I will leave a "Patch by: <your-name>" note in the commit message. How would you like to be referenced, what should I be using for <your-name>?

Oct 5 2021, 4:03 AM · Restricted Project
duck-37 added a comment to D111112: [SCCPSolver] Fix use-after-free in markArgInFuncSpecialization..

Wowsers, this is quite something, and I've learned something today!
But now reading things, and after asking my colleague @momchil.velikov for a second opinion, we agree with your analysis + fix, so thanks for fixing, LGTM.
Do you have commit rights? Would you like this to be committed on your behalf?

Oct 5 2021, 3:52 AM · Restricted Project
duck-37 updated the diff for D111112: [SCCPSolver] Fix use-after-free in markArgInFuncSpecialization..

Add some comments.

Oct 5 2021, 2:11 AM · Restricted Project
duck-37 added a comment to D111112: [SCCPSolver] Fix use-after-free in markArgInFuncSpecialization..

Thanks for looking into this!

I think I may have been bitten by this before (or something similar), but it's easy to forget the details here.... So perhaps you can help me a bit by expanding a on this:

In SCCPSolver::markArgInFuncSpecialization, the ValueState map may be reallocated *after* the initial ValueLatticeElement reference is grabbed, but *before* its use in copy initialization.

I know the operator[] is kind of considered harmful for maps, but in this case that seemed fine and doesn't seem the cause of the problem, is that right? So perhaps you can expand on the reallocation (of the map?) that I don't quite get.

Oct 5 2021, 1:54 AM · Restricted Project

Oct 4 2021

duck-37 requested review of D111112: [SCCPSolver] Fix use-after-free in markArgInFuncSpecialization..
Oct 4 2021, 9:09 PM · Restricted Project