[PATCH] ADT: Shave a pointer off of SmallVector<T, 1>

[Eric Christopher]

On Wed, Jul 1, 2015 at 11:31 AM Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > 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?
>
>
Yep. That sounds like a decent place to stick it.

-eric


> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150701/68d4cf70/attachment.html>