By not pushing any crates to each_linked_rlib_for_lto when no
cross-crate LTO is used, we can avoid special cases elsewhere.

Various LTO cleanups

* Move some special casing of thin local LTO into a single location.
* Move lto_import_only_modules handling for fat LTO earlier. There is no reason to keep it separate until right before pass the LTO modules to the codegen backend. For thin LTO this introduces `ThinLtoInput` to correctly handle incr comp caching.
* Remove the `Linker` type from cg_llvm. It previously helped deduplicate code for `-Zcombine-cgus`, but that flag no longer exists.

Part of rust-lang/compiler-team#908

Because the things in this module aren't MIR and don't use anything
from `rustc_middle::mir`. Also, modules that use `mono` often don't use
anything else from `rustc_middle::mir`.

…classes

Add new Hexagon inline asm register classes:
- reg_pair: GPR double registers (r1:0 through r27:26) for i64/f64 types
- vreg: HVX vector registers (v0-v31) for mode-dependent vector types
- vreg_pair: HVX vector pair registers (v1:0 through v31:30) for vector pairs
- qreg: HVX predicate registers (q0-q3), clobber-only

Key implementation details:
- GPR pairs use LLVM's 'd' register naming (d0-d13) for constraints
- HVX vector pairs use LLVM's 'w' register naming (w0-w15) for constraints
- Register overlap tracking for GPR pair<->single and HVX pair<->single conflicts
- HVX vector types are mode-dependent (64B vs 128B HVX length)

Note: vreg_quad (HVX vector quads) is not supported as LLVM's Hexagon
backend does not support vector quad types in inline asm constraints.

…es, r=JohnTitor

Hexagon inline asm: add reg_pair, vreg, vreg_pair, and qreg register classes

Add three new register classes for the Hexagon inline assembly backend:

* `reg_pair`: GPR double registers (r1:0 through r27:26)
* `vreg`: HVX vector registers (v0-v31)
* `qreg`: HVX predicate registers (q0-q3), clobber-only for now

In cg_gcc ModuleBuffer already only contains a path anyway. And for
moving LTO into -Zlink-only we will need to serialize MaybeLtoModules.
By storing a path cached modules we avoid writing them to the disk a
second time during serialization of MaybeLtoModules.

and provide it to LLVM for better optimization

…nkov

Use closures more consistently in `dep_graph.rs`.

This file has several methods that take a `FnOnce() -> R` closure:
- `DepGraph::with_ignore`
- `DepGraph::with_query_deserialization`
- `DepGraph::with_anon_task`
- `DepGraphData::with_anon_task_inner`

It also has two methods that take a faux closure via an `A` argument and a `fn(TyCtxt<'tcx>, A) -> R` argument:
- DepGraph::with_task
- DepGraphData::with_task

The rationale is that the faux closure exercises tight control over what state they have access to. This seems silly when (a) they are passed a `TyCtxt`, and (b) when similar nearby functions take real closures. And they are more awkward to use, e.g. requiring multiple arguments to be gathered into a tuple. This commit changes the faux closures to real closures.

r? @Zalathar

Start using pattern types in libcore



cc rust-lang/rust#135996

Replaces the innards of `NonNull` with `*const T is !null`.

This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.

Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types

…rcote

preserve SIMD element type information

Preserve the SIMD element type and provide it to LLVM for better optimization.

This is relevant for AArch64 types like `int16x4x2_t`, see also llvm/llvm-project#181514. Such types are defined like so:

```rust
#[repr(simd)]
struct int16x4_t([i16; 4]);

#[repr(C)]
struct int16x4x2_t(pub int16x4_t, pub int16x4_t);
```

Previously this would be translated to the opaque `[2 x <8 x i8>]`, with this PR it is instead `[2 x <4 x i16>]`. That change is not relevant for the ABI, but using the correct type prevents bitcasts that can (indeed, do) confuse the LLVM pattern matcher.

This change will make it possible to implement the deinterleaving loads on AArch64 in a portable way (without neon-specific intrinsics), which means that e.g. Miri or the cranelift backend can run them without additional support.

discussion at [#t-compiler > loss of vector element type information](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/loss.20of.20vector.20element.20type.20information/with/584483611)

Store a PathBuf rather than SerializedModule for cached modules

In cg_gcc `ModuleBuffer` already only contains a path anyway. And for moving LTO into `-Zlink-only` we will need to serialize `MaybeLtoModules`. By storing a path cached modules we avoid writing them to the disk a second time during serialization of `MaybeLtoModules`.

Some further improvements will require changes to cg_gcc that I would prefer landing in the cg_gcc repo to actually test the LTO changes in CI.

Part of rust-lang/compiler-team#908