llvm dev - Mar 2011 - [LLVMdev] Detrimental optimization for reducing relocations.

I was looking into the AsmPrinter and the method EmitSectionOffset which 
contains this code:

--------------------------------------------------------------------------------
  // If the section in question will end up with an address of 0 anyway, we can
  // just emit an absolute reference to save a relocation.
  if (Section.isBaseAddressKnownZero()) {
    OutStreamer.EmitSymbolValue(Label, 4, 0/*AddrSpace*/);
    return;
  }

  // Otherwise, emit it as a label difference from the start of the section.
  EmitLabelDifference(Label, SectionLabel, 4);
}
--------------------------------------------------------------------------------
isBaseAddrfessKnownZero() only returns true for some MCSectionELF sections 
(always false for MachO and COFF), however emitting a symbol value seems to 
always cause a relocation entry, but a label difference does not. I compiled the
factorial program from the demo page with debug info and dumped the relocation 
entries, then I commented out the top block so that EmitLabelDifference was 
always called.

Original:
objdump -r directsymbol.o 
directsymbol.o:     file format elf64-x86-64

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
000000000000005a R_X86_64_PC32     atoi-0x0000000000000004
0000000000000066 R_X86_64_32       .rodata.str1.1
000000000000006f R_X86_64_PC32     printf-0x0000000000000004


RELOCATION RECORDS FOR [.debug_frame]:
OFFSET           TYPE              VALUE 
0000000000000018 R_X86_64_32       .debug_frame
000000000000001c R_X86_64_64       .text
0000000000000040 R_X86_64_32       .debug_frame
0000000000000044 R_X86_64_64       .text+0x0000000000000040


RELOCATION RECORDS FOR [.debug_info]:
OFFSET           TYPE              VALUE 
0000000000000006 R_X86_64_32       .debug_abbrev
0000000000000097 R_X86_64_64       .text
000000000000009f R_X86_64_64       .text+0x0000000000000034
00000000000000c9 R_X86_64_64       .text+0x0000000000000040
00000000000000d1 R_X86_64_64       .text+0x000000000000007c


RELOCATION RECORDS FOR [.debug_line]:
OFFSET           TYPE              VALUE 
000000000000002f R_X86_64_64       .text


RELOCATION RECORDS FOR [.debug_pubnames]:
OFFSET           TYPE              VALUE 
0000000000000006 R_X86_64_32       .debug_info


RELOCATION RECORDS FOR [.debug_pubtypes]:
OFFSET           TYPE              VALUE 
0000000000000006 R_X86_64_32       .debug_info

Then with the reduced code, without the optimization:
objdump -r labeldiff.o 

labeldiff.o:     file format elf64-x86-64

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
000000000000005a R_X86_64_PC32     atoi-0x0000000000000004
0000000000000066 R_X86_64_32       .rodata.str1.1
000000000000006f R_X86_64_PC32     printf-0x0000000000000004


RELOCATION RECORDS FOR [.debug_frame]:
OFFSET           TYPE              VALUE 
000000000000001c R_X86_64_64       .text
0000000000000044 R_X86_64_64       .text+0x0000000000000040


RELOCATION RECORDS FOR [.debug_info]:
OFFSET           TYPE              VALUE 
0000000000000097 R_X86_64_64       .text
000000000000009f R_X86_64_64       .text+0x0000000000000034
00000000000000c9 R_X86_64_64       .text+0x0000000000000040
00000000000000d1 R_X86_64_64       .text+0x000000000000007c


RELOCATION RECORDS FOR [.debug_line]:
OFFSET           TYPE              VALUE 
000000000000002f R_X86_64_64       .text

So, clearly the optimization is making things worse. Would it be okay to delete 
this code and eliminate the isBaseAddressKnownZero? I would like to get rid of 
it.

- Jan

> So, clearly the optimization is making things worse. Would it be okay to
delete
> this code and eliminate the isBaseAddressKnownZero? I would like to get rid
of
> it.
I think it is OK. I can see ld/gdb expecting a relocation, but if that 
is the case we should just have a flag saying it is needed.

If you are really motivated to check it, run the gdb testsuite with your 
patch, but on ELF our debug info is still too big to be usable.
> - Jan
Cheers,
Rafael

----- Original Message ----
> From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Thu, March 10, 2011 4:22:32 PM
> Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations.
> 
> > So, clearly the optimization is making things worse. Would it be okay
to
>delete
> > this code and eliminate the isBaseAddressKnownZero? I would like  to
get rid
>of
> > it.
> 
> I think it is OK. I can see ld/gdb expecting a  relocation, but if that 
> is the case we should just have a flag saying it is  needed.
> 
> If you are really motivated to check it, run the gdb testsuite  with your 
> patch, but on ELF our debug info is still too big to be  usable.
Will the testsuite work on ELF? The patch does not make any functional change 
for the other formats. I know that gdb is okay with the example, but that 
doesn't say very much.

- Jan

> From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Thu, March 10, 2011 4:22:32 PM
> Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations.
> 
> > So, clearly the optimization is making things worse. Would it be okay
to
>delete
> > this code and eliminate the isBaseAddressKnownZero? I would like  to
get rid
>of
> > it.
> 
> I think it is OK. I can see ld/gdb expecting a  relocation, but if that 
> is the case we should just have a flag saying it is  needed.
> 
> If you are really motivated to check it, run the gdb testsuite  with your 
> patch, but on ELF our debug info is still too big to be  usable.
> 
> > -  Jan
> 
> Cheers,
> Rafael
I ran the gdb tests with and without the patch and there was no difference. I 
attached the patch.

Thanks,
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0047_sectionbasezerodelete.patch
Type: application/octet-stream
Size: 2311 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110311/a1a69878/attachment.obj>