[PATCH] D19924: Representing bundle locked groups as fragments in MCAssembler

Derek Schuff via llvm-commits llvm-commits at lists.llvm.org
Fri May 6 11:56:54 PDT 2016


dschuff added a comment.

In general I like this direction too. Here are a few preliminary comments. Wrt mc-relax-all, we haven't completely replaced llc in PNaCl yet; I wouldn't necessarily be against removing mc-relax-all anyway though. We might want to consider how this would impact memory usage, and especially if it's an improvement over the previous "normal" case, then that's a no-brainer.


================
Comment at: lib/MC/MCAssembler.cpp:356
@@ +355,3 @@
+  while (Count > 0) {
+    uint64_t Amount = std::min(Count, (((Offset / BundleSize) + 1) * BundleSize) - Offset);
+    Count -= Amount;
----------------
I guess this code enforces the requirement that nop data not cross bundle boundaries? Can we add back some of the explanatory comments? (here and elsewhere where it makes sense?)

================
Comment at: lib/MC/MCFragment.cpp:194
@@ -195,3 +193,3 @@
   assert(BundleSize > 0 &&
          "computeBundlePadding should only be called if bundling is enabled");
   uint64_t BundleMask = BundleSize - 1;
----------------
Can this assert just go away now?

================
Comment at: test/MC/X86/AlignedBundling/nesting.s:36
@@ -37,1 +35,3 @@
   callq bar
+  .bundle_lock
+  callq bar
----------------
Is there some particular reason why the `align_to_end` has been moved to the first bundle_lock directive here? I think we still have the requirement that a nested directive with the `align_to_end` property makes the bundle be aligned to end even if the first directive doesn't have it.


Repository:
  rL LLVM

http://reviews.llvm.org/D19924





More information about the llvm-commits mailing list