Remove workarounds for DevCom-11055227

[Hari Limaye (hazzlim)]

I have verified that these workarounds are no longer needed.

Closes #6363

[Copilot]

Pull request overview

Removes legacy DevCom-11055227 workaround patterns in the ARM64/NEON portions of vector_algorithms.cpp, primarily by standardizing small constant lookup tables as static constexpr and dropping now-obsolete transition commentary.

Changes:

• Converted several function-local constant arrays used for NEON loads (mask/weight tables) from constexpr to static constexpr.
• Removed DevCom-11055227-related “TRANSITION” comments and adjacent explanatory comments tied to that workaround.

Show a summary per file

File	Description
stl/src/vector_algorithms.cpp	Updates ARM64/NEON constant-table declarations and removes DevCom-11055227 workaround comments.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Low

[Yexuan Xiao (YexuanXiao)]

What is the best practice for using static constexpr variables? Unless constrained by syntax, I generally don't proactively declare constexpr variables as static.

[Alex Guteniev (AlexGuteniev)]

What is the best practice for using static constexpr variables?

Take address? Make it static!

And arrays have their address implicitly taken.

[Stephan T. Lavavej (StephanTLavavej)]

The best practice is for arrays to be static constexpr, but scalars can be plain constexpr. The reason why is that distinct objects need distinct addresses. Even when no code actually cares about the distinctiveness of an object's address, the optimizer typically can't prove that nothing cares about an array being distinct, because arrays are inherently address-taken when used (as soon as a pointer to something is flying around, the optimizer has to worry it might be saved somewhere, and then compared for equality). So if you have a plain constexpr array, it will end up emitting code to push every array element onto the stack during the function call. (Try it with /FAs, or in Compiler Explorer.) A static constexpr array is way better for codegen, as it gets burned into the read-only section in the image (rdata), and the function can just push its address onto the stack.

For ordinary scalar constexpr variables, they are typically not address-taken, so you don't need to bother with static constexpr. (In rare cases they can be, e.g. if passed to std::max(), but sometimes inlining will rescue that anyways.)

There's an annoying exception that in actual constexpr evaluation, static constexpr arrays weren't usable, so you needed to use plain constexpr. I think that finally got fixed recently (C++26?) but I am not keeping as close track of language evolution as I once did.

[A. Jiang (frederick-vs-ja)]

There's an annoying exception that in actual constexpr evaluation, static constexpr arrays weren't usable, so you needed to use plain constexpr. I think that finally got fixed recently (C++26?) but I am not keeping as close track of language evolution as I once did.

That was fixed by WG21-P2647R1 in C++23. Maybe we can start relying on the change.

[Stephan T. Lavavej (StephanTLavavej)]

I'm mirroring this to the MSVC-internal repo. Please notify me if any further changes are pushed, otherwise no action is required.

[Stephan T. Lavavej (StephanTLavavej)]

🦾 🧹 😻