[LLVMbugs] [Bug 13139] New: Really long IR labels generated for gold/arm.cc -O3 (no limit to IR label length)

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13139

             Bug #: 13139
           Summary: Really long IR labels generated for gold/arm.cc -O3
                    (no limit to IR label length)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jvoung at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the IR of the bitcode generated from the gold linker's source file, arm.cc,
I noticed that we generate some labels with over 7000 characters. 

In the function "scan_reloc_for_stub", look for
"for.cond1.preheader.for.cond1.preheader_crit_edge.i.for.cond1.preheader.for.cond1.preheader_crit_edge.i..."

clang -O3 -c -emit-llvm <attached.preprocessed.source> -o temp.bc

(doesn't show up with -O0)

It doesn't crash the compiler, but I wonder if we did not have to manipulate
such long strings, would the compile time for code like arm.cc  be faster... 
Would it be worth limiting the length of these labels?

Timing "llc" it's not much of a difference: 1.034s  vs 1.014s (1.9%) if we
stripped the bitcode first to reduce the length of the labels.  Timing "opt" to
make a run through the bitcode again it's 0.804s vs 0.777s (3.5%) to run
through stripped bitcode. So, definitely not a big deal, but I guess if you are
looking for a percent or two improvement from somewhere...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.