Re: RFA: hookize ADJUST_INSN_LENGTH

[Richard Sandiford <rdsandiford at googlemail dot com>]

Joern Rennecke <joern.rennecke@embecosm.com> writes:
> Quoting Richard Sandiford <rdsandiford@googlemail.com>:
>>> 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...).

But what I'm trying to get at is: why can't the backend tell
shorten_branches about the amount of alignment/misalignment
that the target wants, and where?  Via an attribute or a hook,
I don't mind which.  But it should be declarative, rather than
a part of the shorten_branches algorithm.

Also...

>> 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?

...it looks like arc_reorg already runs shorten_branches in a loop.
Is that right?  So in a sense we already have iteration involving
shorten_branches and the backend.

I realise we want to cut down the number of iterations where possible,
but at the same time, it seems like you're trying to do conditional
execution conversion on the fly during shorten_branches, such that the
rtl doesn't actually represent the instructions we output.  And the
performance problem you're seeing is that those behind-the-scenes
changes are too confusing for the current shorten_branches code to
handle well.  E.g. sometimes you decide to "delete" branches that stay
in the rtl stream as branches, and that got a length in a previous
iteration.

At some point, as you say, you hav have to commit to using a particular
form (conditionally executed or not) in order to avoid cycles.  But that
seems like a conditional execution decision rather than a shorten_branches
decision.  (It'd also be good to represent it in the rtl if possible.)

Richard