Stop using LLVM struct types for array/pointer offset GEPs

[erikdesjardins]

...and just use a byte array with the same size as the element type instead. This avoids depending on LLVM's struct layout to determine the size of the array/pointer element.

Spiritually split out from #121577.

r? @nikic

[saethlin]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 379de30 with merge 7ba692d...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7ba692d (7ba692d484ffb437afc774f11309f398ff2ab358)

[rust-timer]

Finished benchmarking commit (7ba692d): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-2.4%, -1.4%]	4
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.4%	[1.0%, 3.7%]	12
Regressions ❌ (secondary)	2.7%	[1.6%, 3.8%]	23
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[-2.0%, 3.7%]	13

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-9.6%	[-9.9%, -9.3%]	4
All ❌✅ (primary)	-	-	0

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	11
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-0.1%	[-0.2%, -0.0%]	11

Bootstrap: 647.708s -> 643.848s (-0.60%)
Artifact size: 309.95 MiB -> 309.65 MiB (-0.10%)

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[nikic]

I'm not sure this is a particularly useful change to make at this time.

[erikdesjardins]

This isn't really about ptradd anymore. I want to get to a point where we never use LLVM struct types except for scalarpair returns†, which feels like it's almost within reach. That should make it a lot harder for us to accidentally leak Rust/LLVM implementation details into our ABIs, or to create completely broken ABIs like wasm32-unknown-unknown. (In this specific case, it also just feels silly that we generate these full-fidelity types, and then the only thing LLVM does is add up all the fields to compute the size, something we already did.)

But given that this pattern is likely to get a proper untyped representation in the future (with scaled ptradd or something), I'm fine if you want to wait for that.

^{† ...and a few unfortunate special cases: volatile load/store, unadjusted ABI, wasm32-unknown-unknown, and surely some things I haven't found yet that won't be easily changed.}

[wesleywiser]

@nikic Do you think we should wait for a proper untyped representation in LLVM IR as @erikdesjardins mentions or should we consider merging this?

[nikic]

I think it's better to wait. LLVM still has some source element type dependent logic for variable index GEPs, and I don't think there's much benefit to making this change early.

[apiraino]

As per the previous comment, I'll try signaling this with:

@rustbot label -S-waiting-on-review +S-blocked