[PATCH] Re-enable a hook in MCELFObjectTargetWriter to allow target-specific relocationtable sorting and use this hook for Mips.

[Vladimir Stefanovic]

> But it cant introduce a wrong result if another relocation is 1 byte

>  away, no? We just know that that is not possible? If so please add a

>  comment about that.


Yes, Mips instructions length is fixed and at least 2 bytes (2 for micromips and mips16, 4 for mips32 and mips64), so there will always be 2 or 4 bytes offset between 2 instructions.

> Still not there. Which relocation gets matched to another is part of

>  of the semantics of the assembly file. We have to match gas or

>  document that we are incompatible.


Copied the sentence from the generic sortRelocs().

> > ================

> 

> >  Comment at: lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp:366

> 

> >  @@ +365,3 @@

> 

> >  +    // Also find HIs and LOs that are already matched.

> 

> >  +    if (I > 0 && areMatchingHiAndLo(MipsRelocs[I], MipsRelocs[I-1]))

> 

> >  +      setMatch(MipsRelocs[I], MipsRelocs[I-1]);

> 

> > 

> 

> > - rafael wrote:

> 

> > 

> 

> > > Why is this first check for I and I-1 necessary? The main loop should handle it, no?

> 

> > 

> 

> > 

> 

> > It finds 'non-free' %lo's, ie. the ones that are already preceded with a %hi. Then it's easier for the main loop to find a 'free' %lo for a %hi, which are preferred over the 'non-free' ones. As an addition, it remembers %hi's with a matched %lo so the main loop can early exit for them.

> 

> 

> The rules around this area are pretty fuzzy. Lets try to make the code

>  as direct as possible on the first implementation at least. Could you

>  please remove this case and let the main loop handle it?


Moved to the main loop.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7414

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/