search for: mutablearrayref

+1, totally a bug. That’s the domain of MutableArrayRef. -Chris > On Oct 1, 2017, at 6:52 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +1 seems like a bug > > On Sun, Oct 1, 2017 at 12:35 AM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: &g...

...0; An important distinction between `ThinStream` and existing stream implementations is that API encourages implementations to be *zero copy*. Instead of giving it a buffer to write into, it just returns you a slice of the existing buffer. This makes it *very efficient*. Similar to `ArrayRef` / `MutableArrayRef`, I also provide *WritableThinStream* for cases where your data is not read-only. This is another area where functionality is provided that was not present in existing abstractions (i.e. writeability). I have several implementations of this class and some abstractions for working with them. *Byt...

...ators are defined wrong to make this true. While ArrayRef<int> Foo(Something); Foo[0] = 5; will give a compile time error. something like: ArrayRef<int> Foo(Something); std::sort(Foo.begin(), Foo.end()); Will work fine. Is this expected? (FWIW: I expected this to only work with a MutableArrayRef) _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachment...

It is suggested in the documentation that if you would have declared a function parameter as SmallVector<Foo,N>&, it is better to instead declare it as SmallVectorImpl<Foo>&. This makes sense, but it seems to me that it is better still to declare it as ArrayRef<Foo>; a quick test suggests it compiles to the same (highly efficient) code, and adds a bit more flexibility in

...tinction between `ThinStream` and existing stream > implementations is that API encourages implementations to be *zero copy*. > Instead of giving it a buffer to write into, it just returns you a slice of > the existing buffer. This makes it *very efficient*. Similar to > `ArrayRef` / `MutableArrayRef`, I also provide *WritableThinStream* for > cases where your data is not read-only. This is another area where > functionality is provided that was not present in existing abstractions > (i.e. writeability). > > I have several implementations of this class and some abstractions for...

...n/RegisterCoalescer.cpp:2892:0 #12 0x0000000001fd5fc3 (anonymous namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:1468:0 #13 0x0000000001fdd4b6 (anonymous namespace)::RegisterCoalescer::copyCoalesceWorkList(llvm::MutableArrayRef<llvm::MachineInstr*>) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:2962:0 #14 0x0000000001fddf32 (anonymous namespace)::RegisterCoalescer::coalesceLocals() /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:3087:0 #15 0x0000000001fde3a1 (anonymous namespace)::R...

...ators are defined wrong to make this true. While ArrayRef<int> Foo(Something); Foo[0] = 5; will give a compile time error. something like: ArrayRef<int> Foo(Something); std::sort(Foo.begin(), Foo.end()); Will work fine. Is this expected? (FWIW: I expected this to only work with a MutableArrayRef) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170930/bb311c53/attachment.html>