llvm dev - Aug 2016 - help please: how to sort the contents of a "SymbolTableListTraits<GlobalVariable>"?

On 08/04/2016 01:33 PM, David Majnemer wrote:
> You should never be copying or moving around Values.


Why not?  Is that because of this thing you also wrote in the same message:
"use lists are
allocated before the object"?

> An llvm::Value (which GlobalVariable is a subtype of) should exist only in
the heap.
Trying to sort a container of such objects doesn`t require me to contradict that
advice.  The
code I have added only uses "GlobalVariable" via pointers and
references, with the possible
exception of the newly-added copy ctor.

Thanks for your reply.

Regards,

Abe

On Thu, Aug 4, 2016 at 11:41 AM, Abe Skolnik via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 08/04/2016 01:33 PM, David Majnemer wrote:
>
> You should never be copying or moving around Values.
>>
>
>
>
> Why not?  Is that because of this thing you also wrote in the same
> message: "use lists are allocated before the object"?
>
>
Among other things.

They are simply not currently built to be relocated.
attempts to do so will likely result in a huge mess.

my strong recommendation here would be to stop trying to go down this path,
and instead, if you want a sorted list, just put them in a separate
container and sort them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160804/489e0192/attachment.html>

David Majnemer wrote:

   You should never be copying or moving around Values.

Abe wrote:
   Why not?  Is that because of this thing you also wrote in the same
   message: "use lists are allocated before the object"?


Daniel Berlin wrote:
   Among other things.

   They are simply not currently built to be relocated.
   attempts to do so will likely result in a huge mess.

   my strong recommendation here would be to stop trying to go down this path,


Abe: I tried. :-(


[Daniel again]

   and instead, if you want a sorted list,
   just put them in a separate container and sort them.


Yup.  I tried that.  It went "boom". :-(

Maybe the essence what I did wrong when I tried it earlier was that the objects
were
effectively on the stack.  However, if/when using a typical implementation of
either
"std::list" or "std::vector", only the container metadata
should be on the stack [when the
container is a local], with the containees on the heap, no?


Regards,

Abe

> On Aug 4, 2016, at 11:52 AM, Daniel Berlin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> On Thu, Aug 4, 2016 at 11:41 AM, Abe Skolnik via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On 08/04/2016 01:33 PM, David Majnemer wrote:
> 
> You should never be copying or moving around Values.
> 
> 
> 
> Why not?  Is that because of this thing you also wrote in the same message:
"use lists are allocated before the object"?
> 
> 
> Among other things.
> 
> They are simply not currently built to be relocated.
> attempts to do so will likely result in a huge mess.
> 
> my strong recommendation here would be to stop trying to go down this path,
and instead, if you want a sorted list, just put them in a separate container
and sort them.
The thing is that a “SymbolTable” is a “iplist” (it inherit from it) and, iplist
has a “sort()” method, it is not clear why we can’t sort then?

The fact that SymbolTable implementation is breaking one of its public method
does not seem right to me.

Also, in general, the design assuming any instance of a
SymbolTable<GlobalVariabl> is owned by a Module and inspecting the
“parent” using magic trick, seems … broken.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160804/85f651ec/attachment.html>