[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:
http://reviews.llvm.org/D10041
(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).
Tobias
More information about the llvm-commits
mailing list