[llvm] r289579 - ADT: Add OwningArrayRef class.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 19 21:47:22 PST 2016


On Mon, Dec 19, 2016 at 9:24 PM Peter Collingbourne <peter at pcc.me.uk> wrote:

> Sure, I understood what you meant. I meant that I wouldn't take a position
> on whether avoiding the cost of the capacity and the reserve area is worth
> it.
>
> (If pressed I think I'd say no, the average tu doesn't have that many
> vtables, and there are far more egregious wastes of memory in llvm anyway
> (e.g. llvm::DIE) that we should be concentrating on first, but while I was
> adding another thing to vtables I figured it wouldn't hurt to be consistent
> with the others, then rule of three kicked in so seemed reasonable to add
> the abstraction.)
>

Yeah, that's pretty much how I feel too.

Richard, Chandler - I seem to recall this has come up before (whether or
not LLVM would benefit from a dynarray like abstraction) & I don't remember
the backstory on the standards committee for dynarary (which I would've
only heard second hand from one of you, I think). Any extra
context/thoughts you could share here, briefly?

- Dave


>
> Peter
>
>
> On Dec 19, 2016 20:29, "David Blaikie" <dblaikie at gmail.com> wrote:
>
> What I mean is: compare OwningArrayRef to std::vector, not OwningArrayRef
> to manual memory management
>
> On Mon, Dec 19, 2016 at 8:07 PM Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>
> I don't really have a strong opinion about it. It wraps up some manual
> memory management code we used to have in the vtable builder, although I
> couldn't say how beneficial that memory management really is.
>
> Peter
>
> On Mon, Dec 19, 2016 at 7:56 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
> Is this really worth having compared to std::vector? std::dynarray was
> rejected from standardization for that reason, if I understand/heard
> correctly (& OwningArrayRef seems similar to std::dynarray)
>
> On Tue, Dec 13, 2016 at 12:34 PM Peter Collingbourne via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: pcc
> Date: Tue Dec 13 14:24:24 2016
> New Revision: 289579
>
> URL: http://llvm.org/viewvc/llvm-project?rev=289579&view=rev
> Log:
> ADT: Add OwningArrayRef class.
>
> This is a MutableArrayRef that owns its array.
> I plan to use this in D22296.
>
> Differential Revision: https://reviews.llvm.org/D27723
>
> Modified:
>     llvm/trunk/include/llvm/ADT/ArrayRef.h
>
> Modified: llvm/trunk/include/llvm/ADT/ArrayRef.h
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ArrayRef.h?rev=289579&r1=289578&r2=289579&view=diff
>
> ==============================================================================
> --- llvm/trunk/include/llvm/ADT/ArrayRef.h (original)
> +++ llvm/trunk/include/llvm/ADT/ArrayRef.h Tue Dec 13 14:24:24 2016
> @@ -413,6 +413,25 @@ namespace llvm {
>      }
>    };
>
> +  /// This is a MutableArrayRef that owns its array.
> +  template <typename T> class OwningArrayRef : public MutableArrayRef<T> {
> +  public:
> +    OwningArrayRef() {}
> +    OwningArrayRef(size_t Size) : MutableArrayRef<T>(new T[Size], Size) {}
> +    OwningArrayRef(ArrayRef<T> Data)
> +        : MutableArrayRef<T>(new T[Data.size()], Data.size()) {
> +      std::copy(Data.begin(), Data.end(), this->begin());
> +    }
> +    OwningArrayRef(OwningArrayRef &&Other) { *this = Other; }
> +    OwningArrayRef &operator=(OwningArrayRef &&Other) {
> +      delete this->data();
> +      this->MutableArrayRef<T>::operator=(Other);
> +      Other.MutableArrayRef<T>::operator=(MutableArrayRef<T>());
> +      return *this;
> +    }
> +    ~OwningArrayRef() { delete this->data(); }
> +  };
> +
>    /// @name ArrayRef Convenience constructors
>    /// @{
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
>
> --
> --
> Peter
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161220/95b2e857/attachment.html>


More information about the llvm-commits mailing list