Joern Rennecke <joern.renne...@embecosm.com> writes: > 2012-10-04 Joern Rennecke <joern.renne...@embecosm.com> > > * final.c (get_attr_length_1): Use direct recursion rather than > calling get_attr_length. > (get_attr_lock_length): New function. > (INSN_VARIABLE_LENGTH_P): Define. > (shorten_branches): Take HAVE_ATTR_lock_length into account. > Don't overwrite non-delay slot insn lengths with the lengths of > delay slot insns with same uid. > * genattrtab.c (lock_length_str): New variable. > (make_length_attrs): New parameter base. > (main): Initialize lock_length_str. > Generate lock_lengths attributes. > * genattr.c (gen_attr): Emit declarations for lock_length attribute > related functions. > * doc/md.texi (node Insn Lengths): Document lock_length attribute. > > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00383.html
Sorry, this is really just repeating Richard B's comments, but I still don't understand why we need two attributes. Why can't shorten_branches work with the existing length and simply make sure that the length doesn't decrease from one iteration to the next? That seems to be how you implement CASE_VECTOR_SHORTEN_MODE. It also means that we can continue to use the pessimistic algorithm for -O0. You said in your reply that one of the reasons was to avoid "interesting" interactions with ADJUST_INSN_LENGTH. But the previous minimum length would be applied after ADJUST_INSN_LENGTH, so I'm not sure why it's a factor. If lock_length is just an optimisation on top of that, then maybe it would help to split it out. Richard
