[PATCH] Remove copies of MCSubtargetInfo from MCRelaxableFragment

[Rafael Espíndola]

patch 5 looks odd. Why do you need to store a MCSubtargetInfo? Can't
you store just the feature bits and pass just the feature bits to
.encodeInstruction?

On 10 July 2015 at 09:42, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> patch 4 LGTM
>
> On 10 July 2015 at 09:37, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> patch 3 LGTM.
>>
>> On 10 July 2015 at 09:29, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>> Patch 2 LGTM.
>>>
>>> On 10 July 2015 at 09:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>>> Patch 1 LGTM.
>>>>
>>>>
>>>> On 8 July 2015 at 20:30, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>>> Last I checked my `-g -flto` workload, `MCRelaxableFragment` was taking
>>>>> up 4.7% of the heap during LTO.  Since these aren't debug info related,
>>>>> the relative cost is even higher without `-g` (I figure 10% or so?).
>>>>> The struct layout contained a shock: over half of
>>>>> `sizeof(MCRelaxableFragment)` comes from a local copy (!?) of
>>>>> `MCSubtargetInfo`.
>>>>>
>>>>> It was more roundabout than I expected to fix, but this patch series
>>>>> does it.  0001 removes the copy of `MCSchedModel` from
>>>>> `MCSubtargetInfo`, 0002-0004 change the `MCSubtargetInfo` API to prove
>>>>> that only the feature bits get mutated, and 0005 moves the copies of
>>>>> `MCSubtargetInfo` to a cache in `MCContext`.
>>>>>
>>>>> I'd love a pre-commit sanity check from someone for two of these:
>>>>>   - 0001 (the object for `MCSchedModel::GetDefaultMCSubtarget()` doesn't
>>>>>     need to be defined in the header for some reason, does it?) and
>>>>>   - 0003 (I'm touching *all* the targets...)
>>>>>
>>>>> and I've provided the rest of the series (and a combined all.patch) for
>>>>> context.
>>>>>
>>>>>