[polly] r238090 - Use unique_ptr to clarify ownership of ScopStmt

Tobias Grosser tobias at grosser.es
Tue May 26 14:54:50 PDT 2015

On 05/26/2015 08:59 PM, Johannes Doerfert wrote:
> On 05/26, David Blaikie wrote:
>> On Fri, May 22, 2015 at 10:14 PM, Tobias Grosser <tobias at grosser.es> wrote:
>>> vector.
>>> -  Stmts.push_back(Stmt);
>>> +  Stmts.push_back(std::move(Stmt));
>> It looks like these objects aren't polymorphic (it's not like Stmts
>> contains pointers to heterogenous derived objects). If that's the case, you
>> might want to consider whether you can use value rather than pointer
>> semantics.
>> Either a std::vector<ScopStmt> or, if you need object pointer identity, a
>> std::forward_list<ScopStmt> or std::list<ScopStmt>
>> This makes the semantics even simpler - no extra pointer chasing, etc, and
>> can reduce the memory footprint (forward_list reduces the memory footprint
>> a tiny bit (compared to a vector of unique_ptr) but std::list actually
>> increases it because it needs two pointers per node instead of one (a
>> vector of unique_ptrs only has one pointer per node, etc))
> I would really like to change to References or if not possible to
> std::forward_list<Reference>. (I actually did so in the Scalar Codegen
> path with MemoryAcccesses.)

What about the following:


(We do not yet use forward lists as otherwise we would need to add the 
elements to the front which then again require more work to ensure the 
order in which we emit statements in our -analysis output does not change).


More information about the llvm-commits mailing list