Also addressed by D147982.

Looks like this was fixed in D147982.

@zjaffal can you confirm that this version of the patch also fixes your issue?

Fix diff, take two.

Fix diff.

Much better test.

most likely won't be able to get this done fully by tonight, so WIP patch is attached

In D125072#4228326, @duck-37 wrote:

In D125072#4227820, @zjaffal wrote:

It looks like this commit introduced a new crash in llc when building for macos
Here is the link to the reproducer
https://godbolt.org/z/heqaE1jYa

Please take a look and revert if it needs a non-trivial fix

Looking into it now, thanks.

In D125072#4227820, @zjaffal wrote:

It looks like this commit introduced a new crash in llc when building for macos
Here is the link to the reproducer
https://godbolt.org/z/heqaE1jYa

Please take a look and revert if it needs a non-trivial fix

Changed some wording in the review, used a virtual function instead of hardcoded emitNops call so that X86 (and potentially other targets) can use their own implementations if necessary.

In D143802#4119979, @MaskRay wrote:

Fixes https://github.com/llvm/llvm-project/issues/60672

It's not a bug so I'd use Close. Note: without runtime support, the compiler codegen change isn't really useful

Rebase.

Rebase to fix w/ new LLVM version. @paquette ping, this PR has been open for some time now and it's blocking the more important change (preventing XRay pseudo-opcodes from being outlined without needless code duplication)

Rebase.

Rebase.

Rebase, update a few comments.

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

In D122635#3495850, @pcwang-thead wrote:

D125072 does the favor.

Comment clarification and typo fix.

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.

Add newline to end of test case

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

Make clang-format happy.

In D111661#3061399, @SjoerdMeijer wrote:

In D111661#3061016, @duck-37 wrote:

In D111661#3060651, @SjoerdMeijer wrote:

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?

Fix faulty assertion.

In D111660#3061173, @SjoerdMeijer wrote:

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.

Change from if statement to assert.

In D111660#3060585, @SjoerdMeijer wrote:

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.

Make sure replaceAllUsesWith is also removed.

In D111661#3060651, @SjoerdMeijer wrote:

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.

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

Visit with SCCPSolver after replacing users.

In D111112#3042178, @SjoerdMeijer wrote:

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>?

In D111112#3042115, @SjoerdMeijer wrote:

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?

Add some comments.

In D111112#3041838, @SjoerdMeijer wrote:

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.