[PATCH][Review Requested][Compilation Time] Small Vector for Machine Operand

[Andrew Trick]

On Mar 12, 2013, at 2:48 PM, Michael Ilseman <milseman at apple.com> wrote:

> 
> On Mar 12, 2013, at 2:04 PM, Andrew Trick <atrick at apple.com> wrote:
> 
>> 
>> On Mar 12, 2013, at 1:34 PM, Andrew Trick <atrick at apple.com> wrote:
>> 
>>> 
>>> On Mar 12, 2013, at 12:17 PM, Michael Ilseman <milseman at apple.com> wrote:
>>> 
>>>> 
>>>> On Mar 12, 2013, at 11:38 AM, "Nowicki, Tyler" <tyler.nowicki at intel.com> wrote:
>>>> 
>>>>> Sorry for the delayed response.
>>>>> 
>>>>> Thanks for the great review. I didn't realize that using SmallVector may have unforeseen consequence for other backends, just seemed like a move to an LLVM data type.
>>>>> 
>>>>> I am interested in learning more about your future changes to SelectionDAG. How will you resolve physical registers, and are you thinking of getting rid of preRA scheduling?
>>>>> 
>>>>> I'm not sure how we would verify that the preRA scheduler behavior hasn't changed over all backends. Do you have any suggestions?
>>>>> 
>>>> 
>>>> In the mean time, you can try Bill's suggestion of keeping the APIs the same and just issuing a call to reserve(). This should give you the vast majority of your improvements. SmallVector excels over std::vector when you expect to be making many of them, but in this case it's a one-off malloc call.
>>> 
>>> The real savings is from simply reusing the selection DAG scheduler which avoids reallocating the SUnits. In this case the SmallVector is not small, it's giant (probably larger than a page), and sitting right in the middle of my nice dense scheduler object.
>> 
>> It's a 44k SmallVector to be precise. Let's please not replace all std::vectors with SmallVectors!
>> 
> 
> How do you feel about std::vector and reserving it to 44k?

I feel good about that. I'm the one who asked Tyler to do that :)

-Andy