RFA: hookize ADJUST_INSN_LENGTH

[Richard Biener]

On Wed, Oct 31, 2012 at 1:33 PM, Joern Rennecke
<joern.rennecke@embecosm.com> wrote:
> Quoting Richard Sandiford <rdsandiford@googlemail.com>:
>
>>> It's about describing complex interactions of length adjustments that
>>> derive from branch shortening and length added for (un)alignment for
>>> scheduling purposes.  Expressed naively, these can lead to cycles.
>>
>>
>> But shorten_branches should be written to avoid cycles, and I thought
>> your patch did that by making sure that the address of each instruction
>> only increases.
>
>
> This actually gives a very poor branch shortening result for ARC.
> What I did before with the lock_length attribute was only locking in
> increases
> for the length of branches, and preserving a complex set of invariants to
> avoid cycles from the (mis)alignment padding.
>
> Saying that for some instructions, the length locking comes in effect
> only after a few iterations of not permanently increasing the size of
> other instructions is still cycle-safe.
>
>
>>> The length variation for the ARC are not alike: there are branches that
>>> are subject to branch shortening in the usual way, but they might
>>> shrink when other things shrink.  When we are iterating starting at
>>> minimal length and increasing lengths, these branches should be stopped
>>> from shrinking, as they likly will grow back again in the next iteration.
>>> OTOH there are potentially short instructions that are lengthened to
>>> archive scheduling-dictated alignment or misalignment.  These should
>>> be allowed to change freely back and forth.  Unless we have a rare
>>> cycle that only depends on alignments.
>>
>>
>> Hmm, but this is still talking in terms of shorten_branches, rather than
>> the target property that we're trying to model.  It sounds like the
>> property
>> is something along the lines of: some instructions have different
>> encodings
>> (or work-alikes with different encodings), and we want to make all the
>> encodings available to the optimisers.  Is that right?
>
>
> No, not really.  There are lots of redundant encodings, but we have only
> one favourite encoding for each size.  We usually want the shortest version,
> unless we want to tweak the alignment of a following instruction, or in
> the case of unaligned conditional branches with unfilled delay slot, to
> hide the branch penalty (don't ask me why it has that effect...).

Maybe we should split the thing then into a adjust_insn_length attribute
without the iteration parameter and a hook, similar to the various scheduler
hooks, that is special for branch shortening.

Richard.

>
>> If so, that sounds
>> like a useful thing to model, but I think it should be modelled directly,
>> rather than as a modification to the shorten_branches algorithm.
>
>
> The shorten_branches algorithm can't give the correct result without
> taking these things into account.  Also, instruction lengths are needed
> to know the requirements.  So, do you want me to run a scheduling
> pass in each iteration of shorten_branches?
>
>
>> Is the alignment/misalignment explicitly modelled in the rtl?  If so, how?
>> Using labels, or something else?
>
>
> No, it works with instruction addresses during branch shortening, and
> extra bits in cfun->machine during instruction output to keep track of
> the current alignment.