[RFC] Remove User::OperandList

[Pete Cooper]

Actually, looking at 0006 more, I think you’re right that I made too small a change.

Folding away ‘Us' being 0 in the new operator new makes sense.  The operand list should be a nullptr after this, something i can assert in allocHungOffUses, and the call to Use::init(Start, End) wasn’t doing anything as we had no uses.  I’ll fold all that cleanup in to 0006, and the remainder will be in 0008.

Cheers,
Pete
> On Jun 9, 2015, at 10:38 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> 
>> This logic looks all wrong to me.  Firstly, `Us` is always 0, so you can
>> factor it out.
>> 
>> More importantly, why are you co-allocating a `Use`, when the uses are
>> hung-off?  Shouldn't this co-allocate a `Use*`, if anything?  Or does
>> that wait for 0008?
>> 
>> It also seems strange/wrong to be pointing `OperandList` at anything
>> here -- I feel like it should start out as `nullptr`.
>> 
>> Maybe this would make more sense squashed with 0008.  Let me know if I'm
>> just missing something, too.
> Yeah, i should have explained this one better.  Ultimately i was trying to move all the hung off subclasses to the new version of operator new without any other changes in behavior.  Given that they all used to call new(size, 0), i made this version of new initially do exactly that and have the 0 too.
> 
> This version of new does set the HasHungOffUses boolean to true so as to allow the asserts that we only use the hung off uses methods when allowed.
> 
> Would you prefer I squash it, improve the commit comments, or leave it as is given the explanation here?  I can also elaborate more if i didn’t explain it well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150610/fe2a673e/attachment.html>