[llvm] r255902 - Avoid explicit relocation sorting most of the time.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 14 14:10:08 PST 2016


On Thu, Jan 14, 2016 at 12:33 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> >> +static int cmpRel(const ELFRelocationEntry *AP, const
> ELFRelocationEntry
> >> *BP) {
> >> +  const ELFRelocationEntry &A = *AP;
> >> +  const ELFRelocationEntry &B = *BP;
> >> +  if (A.Offset != B.Offset)
> >> +    return B.Offset - A.Offset;
> >> +  if (B.Type != A.Type)
> >> +    return A.Type - B.Type;
> >> +  return 0;
> >
> >
> > This dropped the unreachable present in the prior version (which I just
> > commented on as well) - intentionally?
> >
>
> It was, sorry for taking so long to reply, I missed this before going
> on vacations.
>
> The story of that function is
>
> * We use to have some non determinism on the order relocations were
> created (walking a map/set of pointer?)
> * We started sorting to make it deterministic.
> * We got a target hook to implement mips craziness.
> * At some point the non determinism was fixed.
> * With this patch the function is now just part of the mips implementation.
>
> My thinking was that it was then OK for two relocations to compare
> equal, since they were created in a deterministic order. I now see
> that that thinking is bogus since different qsort implementations
> would produce different results. r257796 uses the assert you
> suggested.
>

Dandy - thanks!


>
> Thanks,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160114/6e4dd995/attachment.html>


More information about the llvm-commits mailing list