Repository navigation
Rust doesn't use niche in reference (or pointer) to slice #132235
Description
From reddit thread: why can't rust optimize the size of Option<Option<&str>>?
Indeed, in spite of the fact that &str doesn't all use more than half of possible bit sequences (top bit of 2nd word is always zero, plus first word can not be zero) only Option<&str> is optimized
Would it make sense to teach compiler about that niche or is it prevented by some deeper issue?
Activity
workingjubilee commentedon Oct 27, 2024
Duplicate of #119507
the8472 commentedon Oct 27, 2024
I don't think that's correct. #119507 is about using niches across fields. This one is about having niches in slice lengths.
And I've attempted to improve that in #116542 but so far perf hasn't been looking good. Maybe because the IR gets more complicated.
workingjubilee commentedon Oct 27, 2024
@the8472 Isn't it a duplicate of #125363 then?
workingjubilee commentedon Oct 27, 2024
In any case, I don't really think having a zillion tiny issues regarding the layout code, which is a big ball of mud, is very helpful. It would be better to collect the various possible optimizations and reason about them in a central manner, rather than trying to make tiny adjustments to spot-fix the code.
the8472 commentedon Oct 27, 2024
#125363 is similar to #119507 actually.
And having a "more niche optimizations" super issue would help. But some of the sub-issues are still useful because some specific cases can likely be fixed without difficult perf tradeoffs while others are less certain.
workingjubilee commentedon Oct 27, 2024
Honestly, I'm not sure why your PR #116542 is seemingly both trying to add metadata and alter the layout of slices.
workingjubilee commentedon Oct 27, 2024
The fundamental issue is that all of the issues we're discussing are trying to do the same thing: "There are two niches, one in each of two separate parts of this. Optimize the layout based on that."
In that regard, a struct and a slice should not be treated significantly differently.
the8472 commentedon Oct 27, 2024
This issue isn't about jointly using two pre-existing niches. It's about adding a new set of niches to the length field in slice-refs, by exploiting the isize::MAX bytes upper limit, something we're currently not doing.
They're based on the same thing, derived from the validity ranges of the fields.
workingjubilee commentedon Oct 27, 2024
They may be based on the same thing, but that doesn't mean the changes are functionally dependent in the implementation.
workingjubilee commentedon Oct 27, 2024
...Unless they are, in which case that segment of the layout code is possibly in even more dire need of being scrapped and rewritten than I thought.
the8472 commentedon Oct 27, 2024
I mean if we define the slice length field validity range - which currently isn't explicitly set and so defaults to the same validity as usize - then both metadata and niches fall out of that automatically. Treating them differently for the purpose of llvmir metadata and niche calculation would take extra effort.
workingjubilee commentedon Oct 27, 2024
I suppose I'll reopen this then, but now I'm wondering if we can convince the layout code that
&[T]is secretly a funny-lookingstruct.the8472 commentedon Oct 27, 2024
I think layout code should already be seeing an univariant ADT with two fields and scalarpair abi. My PR does result in layout changes.
vrtgs commentedon Oct 28, 2024
The issue with this is that when T is a zst, it is now okay for a
&[T]to have more thanisize::MAXelementsAlso
isize::MAXis an even bigger range than the null optimization, so I think it should be favored instead of the null optimization if only one niche optimization can be applied