RFA: hookize ADJUST_INSN_LENGTH (Was: RFA: Add lock_lenth attribute to support the ARC port)

[Joern Rennecke]

Quoting Richard Biener <richard.guenther@gmail.com>:

> Apart from the iteration_threshold the hookization would be straight-forward.
> Now I cannot decipher from the patch what functional change it introduces ;)

The only change occurs if we reach an iteration count of MAX_INT iterations -
which should already be indicative of a problem.

At the MAX_INTth iteration, we will apply the length locking logic to
instructions inside a delay slot sequence as well.

If we disregard this exceptional case, there should be no functional changes
unless someone defines TARGET_ADJUST_INSN_LENGTH.

uid_lock_length gets initialized to allocated with XCNEWVEC.  So, in
particular, the elements corresponding to instructions inside delay slot
sequences are initialized to zero.

As default hook sets *iter_threshold to MAX_INT when inside a delay sequence,
and doesn't change length, the max operation with uid_lock_length is a no-op,
and *niter < iter_threshold is true, hence a length change results in
updating the length immediately, without changing uid_lock_length.

In the case that we are not inside a delay slot sequence, the default hook
leaves iter_threshold as 0, and applies ADJUST_INSN_LENGTH.  Thus, when niter
is 0 or larger, as is the case for the ordinary looping operation, we
always find *niter >= iter_threshold, and thus apply the length  
locking mechanism.

If we are in the preliminary pass, or doing the single !increasing iteration,
niter is set to -1, so *inter < iter_threshold is always true, so again we
update the length immediately.

> There are also ony 10 users of ADJUST_INSN_LENGTH, not enough to
> warrant introducing a hook without removing the macro IMHO.

Ok, I can prepare a patch for that, even though it makes it even a bit
less obvious that there's no functional change.

What about the preparatory patch
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02527.html ?
Can I check that in now?