Re: get_attr_length_1 don't call the fallback function

[Christian BRUEL <christian dot bruel at st dot com>]

ok, thanks. I didn't think that it was allowed to have some 
insns_lengths entries unset, although shorten_branches was called.

That means that some insns where emitted without invalidating the 
addresses (calling init_insn_lengths).

Without it, it looks to me that all subsequent addresses to the SEQUENCE 
become invalid, but are not invalidated. I'm not sure if this is an 
actual issue, this is just for the record (actually dynamically 
maintaining the lengths/addresses would be the best do do)

Best Regards

Christian

Ian Lance Taylor wrote:
> Christian BRUEL <christian.bruel@st.com> writes:
>
>
> > Is it normal/expected that get_attr_length_1 calls get_attr_length,
> > instead of the callback_fn when recursively called from a SEQUENCE
> > stmt?
> >
> > When it is called from get_attr_min_length, we can get the wrong
> > value, which is most of the time only an heuristic issue, but the sh4
> > is very sensitive to it (e.g to compute short conditional branch
> > distances), when INSN_ADDRESSES_SET_P () is not set.
> >
> > thanks for clarifying my view of this piece of code, or eventually
> > allow me to commit the change if it happens to be an issue.
>
>
> I dn't think your patch is correct.  I believe that it is possible for
> a sequence to have a new UID not recorded in insn_lengths[], but for
> the sequence to be composed of insns which UIDs which are recorded in
> insn_lengths.
>
> So, instead of calling get_attr_length, the code should call
>     get_attr_length_1 (XVECEXP (body, 0, i), fallback_fn)
>
> That patch is preapproved if it passes bootstrap and testing.
>
> Thanks.
>
> Ian