New Iteration of subregister liveness patches

[Matthias Braun]

> On Dec 10, 2014, at 10:36 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Wed, Dec 10, 2014 at 10:31 AM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote:
> 
>> On Dec 10, 2014, at 9:28 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> On Tue, Dec 9, 2014 at 5:32 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote:
>> Ok,
>> 
>> I just commited the changes to svn trunk. Thanks everyone, esp. Renato and Quentin, for the detailed reviews!
>> 
>> SubRegisterLiveness is available as a subtarget switch now, but not enabled by any of the targets yet, as most of them need some additional fixing/testcase changes which I'll address in subsequent commits.
>> 
>> For the record: I did fix many but not all issues mentioned in the reviews. The following is still missing:
>> 
>> - Manually creating a single linked list in the LiveInterval class. The alternatives to this are:
>>     a) Using the double linked list provided by llvm.
>>     b) Turning the manual single linked list into a full featued ADT in llvm.
>> 
>> Why not std::forward_list ?
> 
> As far as I know the STL list containers are non-intrusive which is probably even more wasteful as you need an extra object (with memory allocator alignment padding) for each list element.
> 
> They aren't intrusive, but that doesn't mean you need an extra object - it's still just a single allocation per node, containing the element type and a pointer.

I just tried using the non-intrusive list and failed: The code was using a BumpPtrAllocator which was only available on demand at the places where new SubRanges are created (since we do not want to store a reference to the BumpPtrAllocator into every LiveRange). I don't see a way to have the STL list use the BumpPtrAllocator without blowing up the list with a reference to the BumpPtrAllocator (granted in this instance it's probably not too important to actually use a BumpPtrAllocator. So I'm at that point again where the STL just feels like a huge bunch of complicated abstractions (I just spent >30 minutes making sense of complicated libcxx headers) which in the end are still not flexible enough for all use cases...

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141210/74e17990/attachment.html>