Re: [PR24444] speed up locview resolution wiht relaxable frags

[Alexandre Oliva <aoliva@redhat.com>]

On Apr 14, 2019, Alan Modra <amodra@gmail.com> wrote:

> Yes, I believe so.  In fact, fr_fix is really unsigned.  Also, it is
> an error for rs_org frags to go backwards.

Nice, that makes things simpler.

>> Tested on x86_64-linux-gnu, native and cross to xtensa-elf.  No new
>> testcase; the issue was just performance, not output correctness.  Ok to
>> install?

> Um, the testcase object file after this patch differs from the
> original.  First readelf -wi difference shown below.

Which testcase was that?  I didn't catch that one.

>> +  /* If any frag from frag2, inclusive, to frag1, exclusive, has a
>> +     nonzero fixed length, the addresses won't be the same as long as
>> +     we reach frag1.  */
>> +  bfd_boolean maybe_same_addr = off1 == 0 && off2 == (valueT)frag2->fr_fix;

> Ins't it true that if the symbol offsets are not at exactly the above
> values, then you already know the result and there's no need to
> traverse the frags?  This is assuming you can't .org backwards, which
> is the case.

Not entirely, no.  Although the comments state we assume a certain
ordering of frags, the assumption is only valid for O_gt operations
arising from the location view machinery.  It doesn't hurt if we resolve
other O_gt operations if we can find the result, but those could have
frags in the opposite order.

Now, O_gt is not exactly the operation the location view machinery
needs; O_ne (or, after negation, O_eq) would be more like it.  IIRC the
reason I went for O_gt was just that it was resolved early in a lot more
cases than O_eq.  Now, with this kind of fallback, we could actually
introduce another operation kind that (i) resolves to zero if frags are
not in the same (sub)section, and (ii) can safely make the optimization
you suggested for frags in the same (sub)section, with the extra benefit
that we know we won't ever search all the way to the end of the frag
linked list without finding the other frag: we could assert-check that,
and stop the search at the first nonzero-fr_fix.

Would a new op with this semantics (O_incview?, vs reset view) be
preferred?

> The following makes the changes I'm suggesting, and simplifies a few
> more things.

Thanks, I'll wait for a response to the question above before taking
further action on this, but I'll likely integrate your change (credited
in the ChangeLog) in the patch regardless.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe