[PATCH] ADT: Shave a pointer off of SmallVector<T, 1>
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed Jul 1 11:31:16 PDT 2015
> On 2015-Jun-30, at 22:58, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
> On Tue, Jun 30, 2015 at 10:54 PM Duncan Exon Smith <dexonsmith at apple.com> wrote:
> I agree it's probably worth formalizing a smaller vector type, but nothing specifically in mind -- I just noticed when looking at the struct layout of MCRelaxableFragment with Pete that the SmallVector<MCFixup,1> was 56 bytes instead of the 48 bytes I thought it would be.
>
> (BTW, it's crazy that every relaxable fragment carries around a full copy of the MCSubtargetInfo. Until today I thought that was a reference!)
>
> -- dpn
>
> Gack. That's pretty painful. Perhaps changing it to a reference to a unique STI that's kept on the side somewhere in a map? Or something...
>
> -eric
Yeah, something like that should work. Note that this is *only* necessary
when we're coming from actual assembly (such as inline asm). If we're
getting the STI from the MI-layer it's already immutable (thanks to the
subtarget cache stuff you did). Maybe a MCSubtargetInfo cache in the
MCContext or something?
>
> es
>
> On Jun 30, 2015, at 8:52 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>> Is there a specific place where we're storing SmallVectors in a datastructure that you're trying to optimize with this? It might be worth investing in a more general small-sizeof vector than TinyPtrVector. The way the SmallVector currently works (such as actually containing a 3 pointer "vector header") imposes some fundamental limitations on its sizeof.
>>
>> There are various standard ways to greatly reduce sizeof of vectors especially in 64-bit address spaces (and certain assumptions on the OS...) where often the high bits are redundant, allowing the vector header to be compressed to a single pointer in size across a very large size range. Even without the spacious high-bits of a 64-bit address space, we can often store at least up to size 4 or 8 in the low bits, which for many use cases is plenty in the common case.
>>
>> (to be clear, I think this patch makes sense; just had a high-level question)
>>
>> -- Sean Silva
>>
>> On Tue, Jun 30, 2015 at 5:34 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> I'd just commit this, but I want to check:
>>
>> 1. Are my static asserts valid under MSVC? Sanitizers? If not, what
>> *is* a portable way to check that we don't waste memory here?
>> 2. I like them in SmallVector.h (assuming they're portable).
>> Anyone strongly prefer ADTTests?
>>
>> Avoid an unused byte -- which for `sizeof(T) >= sizeof(void *)` costs
>> a pointer -- on `SmallVector<T, 1>`. Shave the same byte off of
>> `SmallVector<T, 0>`. Otherwise, no functionality change.
>>
>> Note that `SmallVector<T, 0>` has the same memory footprint as
>> `SmallVector<T, 1>`, which seems like a bug to me. We should probably
>> fix that too.
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list