[PATCH][MC] Bundle alignment: Invalidate relaxed fragments

[Derek Schuff]

I believe LastValidFragment being NULL is the starting state, and in
any case isValidFragment and ensureValid already handle it correctly.
It does seem possible in principle that the first fragment in a
section is relaxable, so it seems like stuff should still work in that
case.

I do need to fix that comment though, new patch attached.

On Thu, Jan 31, 2013 at 4:09 PM, Eli Bendersky <eliben at google.com> wrote:
>    // Otherwise, reset the last valid fragment to this fragment.
>    const MCSectionData &SD = *F->getParent();
> -  LastValidFragment[&SD] = F;
> +  LastValidFragment[&SD] = F->getPrevNode();
>  }
>
> Is there anything intelligent we can say/assert about this happening
> to the first fragment (in which case getPrevNode() returns NULL)?
>
> Eli
>
>
>
>
> On Thu, Jan 31, 2013 at 3:13 PM, Derek Schuff <dschuff at google.com> wrote:
>> Currently, when a fragment is relaxed, its size is modified, but its
>> offset is not (it gets laid out as a side effect of checking whether
>> it needs relaxation), then all subsequent fragments are invalidated
>> because their offsets need to change. When bundling is enabled,
>> relaxed fragments need to get laid out again, because the increase in
>> size may push it over a bundle boundary. So instead of only
>> invalidating subsequent fragments, also invalidate the fragment that
>> gets relaxed, which causes it to get laid out again. This patch also
>> has the same effect even in the non-bundling case, which isn't
>> strictly necessary, but it makes the code simpler and the cost is low
>> (it just means that one extra fragment gets laid out on each
>> relaxation pass).
>> This patch also fixes some trailing whitespace and fixes the
>> bundling-related debug output of MCFragments.
>>
>> -Derek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: relax-at-bundle-end.diff
Type: application/octet-stream
Size: 4042 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130131/f5338381/attachment.obj>