Make transpose const and inline

[SUPERCILEX]

r? @scottmcm

• These should have been const from the beginning since we're never going to do more than a transmute.
• Inline these always because that's what every other method in MaybeUninit which simply casts does. :) Ok, but a stronger justification is that because we're taking in arrays by self, not inlining would defeat the whole purpose of using MaybeUninit due to the copying.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[scottmcm]

If you make these just #[inline] instead of #[inline(always)], I'll approve it right away.

But for always you need to make a case that it actually matters to have the stronger version.

[SUPERCILEX]

I guess I don't understand when #[inline] wouldn't fire vs. #[inline(always)]. As for why the stronger version matters, if the compiler ever decides not to inline we end up with a memcpy whereas inlining blocks this memcpy.

[scottmcm]

Right, the inlining is clearly important. But the main thing that, compared to nothing, #[inline] actually does on generic methods is force it to be available in all CGUs.

Whereas inline-vs-inline(always) in comparison is just the difference between inlinehint and alwaysinline https://llvm.org/docs/LangRef.html#function-attributes, so we generally don't use always. If LLVM really thinks that sometimes it's not worth doing despite the inlinehint, odds are that we should probably let it make that choice. Sometimes we override it, where someone shows that it's worth it, but non-always #[inline] seems sufficient in your above example.

So let's start with non-always, and can always put it there later if needed.

[SUPERCILEX]

Right, the inlining is clearly important. But the main thing that, compared to nothing, #[inline] actually does on generic methods is force it to be available in all CGUs.

Interesting, was able to find this. I still don't think I get it, but it kind of seemed like inline leads to a potentially major hit and then always doesn't matter on top of that.

If LLVM really thinks that sometimes it's not worth doing despite the inlinehint, odds are that we should probably let it make that choice.

Except that transpose is supposed to generate no code since it's just a cast. If LLVM doesn't inline, that would probably indicate a bug or some truly big-brain stuff. 😆

Anyway, downgraded.

[SUPERCILEX]

@rustbot ready

[scottmcm]

@bors r+

[bors]

📌 Commit 1a1ebb0 has been approved by scottmcm

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1a1ebb0 with merge fa91a1fe99106e14fa44eacbbfcf76a787afb6db...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] regex_automata test:false 10.399
[RUSTC-TIMING] regex test:false 10.838
[RUSTC-TIMING] salsa_macros test:false 2.927
   Compiling salsa v0.17.0-pre.2
rustc: /checkout/src/llvm-project/llvm/include/llvm/CodeGen/MachineInstr.h:506: llvm::MachineOperand& llvm::MachineInstr::getOperand(unsigned int): Assertion `i < getNumOperands() && "getOperand() out of range!"' failed.
[RUSTC-TIMING] tracing_attributes test:false 3.394
rustc exited with signal: 6 (SIGABRT) (core dumped)
error: could not compile `tracing-attributes`
Caused by:
Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name tracing_attributes --edition=2018 /cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.22/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C debuginfo=0 -Zunstable-options --check-cfg 'values(feature, "async-await")' --check-cfg 'names()' --check-cfg 'values()' -C metadata=94c3cd2c5427dc2a -C extra-filename=-94c3cd2c5427dc2a --out-dir /checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps -L dependency=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps --extern proc_macro2=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps/libproc_macro2-0fb922aca1091b45.rlib --extern quote=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps/libquote-2b2b5ad8408c0769.rlib --extern syn=/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps/libsyn-c0b14e37bec48564.rlib --extern proc_macro --cap-lints allow -Z binary-dep-depinfo` (exit status: 254)
[RUSTC-TIMING] thiserror_impl test:false 3.258
[RUSTC-TIMING] pulldown_cmark test:false 11.288
[RUSTC-TIMING] notify test:false 8.944
[RUSTC-TIMING] regex_syntax test:false 16.336

[SUPERCILEX]

@scottmcm can you rerun this? I don't how this failure could be related:

Compiling salsa v0.17.0-pre.2
rustc: /checkout/src/llvm-project/llvm/include/llvm/CodeGen/MachineInstr.h:506: llvm::MachineOperand& llvm::MachineInstr::getOperand(unsigned int): Assertion `i < getNumOperands() && "getOperand() out of range!"' failed.

[scottmcm]

Agreed that that's a super-weird error.

@bors retry