[PATCH] [MC] Proper handle labels when -mc-relax-all flag is used

Mark Seaborn mseaborn at chromium.org
Wed Jun 10 14:32:55 PDT 2015


================
Comment at: lib/MC/MCELFStreamer.cpp:77
@@ +76,3 @@
+      size_t Offset = DF->getContents().size();
+      for (const MCSymbol &Symbol : Assembler.symbols()) {
+        MCSymbolData &SD = Symbol.getData();
----------------
This logic looks OK.  However, doesn't this take O(n) time in the number of symbols that have been created so far?  I'm concerned that this could lead to compilation taking O(n^2) time in the size of the module.  (Quadratic time per function would be bad, but quadratic time per module would be even worse. :-( )

================
Comment at: test/MC/X86/AlignedBundling/rodata-section.s:2
@@ +1,3 @@
+# RUN: llvm-mc -triple=i686-nacl -filetype=obj %s -o - | \
+# RUN: llvm-objdump -disassemble -no-show-raw-insn - | FileCheck %s
+# RUN: llvm-mc -triple=i686-nacl -filetype=obj -mc-relax-all %s -o - | \
----------------
Nit: Indent "llvm-objdump", because this is a continuation line (it follows a "\").

Same below.

================
Comment at: test/MC/X86/AlignedBundling/rodata-section.s:6
@@ +5,3 @@
+
+        .bundle_align_mode 5
+        .text
----------------
Nit: Is this redundant if you're also using "-triple=i686-nacl"?  (Or maybe it's only redundant in the pnacl-llvm branch?)

================
Comment at: test/MC/X86/AlignedBundling/rodata-section.s:12
@@ +11,3 @@
+foo:
+        subl	$12, %esp
+# CHECK: 3: movl $14, 8(%esp)
----------------
Nit: It would make the test clearer if you omitted parts that aren't necessary for reproducing the bug, i.e.
 * "foo" label
 * prologue and epilogue
 * call to "bar"
etc.

================
Comment at: test/MC/X86/AlignedBundling/rodata-section.s:23
@@ +22,3 @@
+        popl	%ecx
+        jmp	  *%ecx
+
----------------
Nit: Can you make the alignment indentation consistent?

http://reviews.llvm.org/D10325

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






More information about the llvm-commits mailing list