[llvm-commits] [llvm] r164724 - in /llvm/trunk: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp test/MC/MachO/i386-large-relocations.s

[Jim Grosbach]

Actually, yes. This problem is isolated to 32-bit. 64-bit uses a different relocation model which avoids this issue.

Problems of this nature end up just making LTO for 32-bit more complex, not impossible. For example, a possible option would be to automatically sub-divide the linked bitcode into multiple translation units for codegen, thus creating multiple object files.

-Jim

On Oct 19, 2012, at 10:02 AM, Alexander Potapenko <glider at google.com> wrote:

> Out of curiosity: does this only apply to 32-bit apps (I guess no). Does the problem make LTO on Mac impossible at all, or just more complex?
> 
> On Oct 19, 2012 8:53 PM, "Jim Grosbach" <grosbach at apple.com> wrote:
> Hi Alexander,
> 
> Unfortunately, that's the case. This is running into a limitation of the MachO file format and reducing the size of the file is the necessary solution.
> 
> -Jim
> 
> On Oct 19, 2012, at 2:10 AM, Alexander Potapenko <glider at google.com> wrote:
> 
> > Ok, I've read your IRC log and it looks like the issue can't be fixed
> > that easily.
> >
> > On Thu, Oct 18, 2012 at 2:24 PM, Alexander Potapenko <glider at google.com> wrote:
> >> The following patch allows me to link my code, but I'm not sure if it
> >> is correct to reset the type here. WDYT?
> >>
> >> Index: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp
> >> ===================================================================
> >> --- lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (revision 166174)
> >> +++ lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (working copy)
> >> @@ -376,6 +376,9 @@
> >>     // pedantic compatibility with 'as'.
> >>     Type = A_SD->isExternal() ? (unsigned)macho::RIT_Difference :
> >>       (unsigned)macho::RIT_Generic_LocalDifference;
> >> +    if (FixupOffset > 0xffffff) {
> >> +      Type = macho::RIT_Vanilla;
> >> +    }
> >>     Value2 = Writer->getSymbolAddress(B_SD, Layout);
> >>     FixedValue -= Writer->getSectionAddress(B_SD->getFragment()->getParent());
> >>   }
> >>
> >> On Thu, Oct 18, 2012 at 1:03 PM, Alexander Potapenko <glider at google.com> wrote:
> >>> Hi Jim,
> >>>
> >>> We've started to trigger exactly this fatal error (trying to emit a
> >>> relocation with FixupOffset > 0xffffff) when compiling a large source
> >>> file with AddressSanitizer
> >>> (http://code.google.com/p/chromium/issues/detail?id=156005)
> >>> Is it possible to use the macho::RIT_Vanilla relocation type for such
> >>> cases? If it is not, are there any other workarounds except reducing
> >>> the size of the file?
> >>>
> >>> On Mon, Oct 1, 2012 at 8:19 PM, Jim Grosbach <grosbach at apple.com> wrote:
> >>>> Sweet! Thanks, Ben.
> >>>>
> >>>> -Jim
> >>>>
> >>>> On Oct 1, 2012, at 8:18 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> >>>>
> >>>>>
> >>>>> On 01.10.2012, at 03:03, Chandler Carruth <chandlerc at google.com> wrote:
> >>>>>
> >>>>>> On Wed, Sep 26, 2012 at 2:27 PM, Jim Grosbach <grosbach at apple.com> wrote:
> >>>>>> Author: grosbach
> >>>>>> Date: Wed Sep 26 16:27:45 2012
> >>>>>> New Revision: 164724
> >>>>>>
> >>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=164724&view=rev
> >>>>>> Log:
> >>>>>> X86_32: Large Symbol+Offset relocations.
> >>>>>>
> >>>>>> If the offset is more than 24-bits, it won't fit in a scattered
> >>>>>> relocation offset field, so we fall back to using a non-scattered
> >>>>>> relocation.
> >>>>>>
> >>>>>> rdar://12358909
> >>>>>>
> >>>>>> Added:
> >>>>>>   llvm/trunk/test/MC/MachO/i386-large-relocations.s
> >>>>>>
> >>>>>> Jim, it looks like this is the slowest running test in the entire regression test suite now... it runs for over 30s on my system, where the total lit runtime is 52 seconds =/
> >>>>>>
> >>>>>> Is there any way to prune it down to a smaller test? Or maybe there is some N^2 aspect to this?
> >>>>>>
> >>>>>> The time appears to go to llvm-mc rather than macho-dump, but I've not really dug into why. I just wanted to let you know.
> >>>>>
> >>>>> It just used an extremely complicated way to emit a stream of zero bytes. r164945 brings it down from 27s to 0.6s in a Debug+Asserts build.
> >>>>>
> >>>>> - Ben
> >>>>
> >>>> _______________________________________________
> >>>> llvm-commits mailing list
> >>>> llvm-commits at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>>
> >>>
> >>>
> >>> --
> >>> Alexander Potapenko
> >>> Software Engineer
> >>> Google Moscow
> >>
> >>
> >>
> >> --
> >> Alexander Potapenko
> >> Software Engineer
> >> Google Moscow
> >
> >
> >
> > --
> > Alexander Potapenko
> > Software Engineer
> > Google Moscow
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/de56b1f6/attachment.html>