[PATCH] D35907: [StackColoring] Update TBAA information in stack coloring pass

Hiroshi Inoue via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jul 29 09:06:32 PDT 2017


inouehrs marked 7 inline comments as done.
inouehrs added inline comments.


================
Comment at: include/llvm/CodeGen/MachineFunction.h:664
 
+  /// getMachineMemOperand - Allocate a new MachineMemOperand by copying
+  /// an existing one, replacing only AliasAnalysis information.
----------------
MatzeB wrote:
> Don't repeat the method name in the doxygen comment (old code does it, new code shouldn't).
Fixed.


================
Comment at: lib/CodeGen/ScheduleDAGInstrs.cpp:154
 /// ptrtoint+arithmetic+inttoptr sequences.
-static void getUnderlyingObjects(const Value *V,
-                                 SmallVectorImpl<Value *> &Objects,
-                                 const DataLayout &DL) {
+void llvm::getUnderlyingObjects(const Value *V,
+                          SmallVectorImpl<Value *> &Objects,
----------------
hfinkel wrote:
> Please rename this function if you make it non-static. The function we have right now in ValueTracking is called GetUnderlyingObjects, but if we were to rename it follow our coding conventions we'd have a conflict with the name of function function. How about `getUnderlyingObjectsForCodeGen`?
I renamed it getUnderlyingObjectsForCodeGen and moved into ValueTracking.cpp.


================
Comment at: lib/CodeGen/StackColoring.cpp:40
 #include "llvm/CodeGen/PseudoSourceValue.h"
+#include "llvm/CodeGen/ScheduleDAGInstrs.h" // for getUnderlyingObjects
 #include "llvm/CodeGen/SlotIndexes.h"
----------------
MatzeB wrote:
> Instead of documenting why you need to import a scheduling header here, just put the function into an apropriate header (as above) :)
Moved to ValueTracking.h.


================
Comment at: lib/CodeGen/StackColoring.cpp:917
+    // We keep both slots to maintain TBAA metadata later.
+    // FIXME: It is conservative. We can keep TBAA metadata
+    // if TBAA information of two slots match.
----------------
hfinkel wrote:
> I'd remove this FIXME. It is not clear to me that there is a well-defined way to do this in general. A single alloca could be accessed at different times by accesses with incompatible TBAA metadata so long as some access compatible with both, or data dependence, keeps the correct ordering. As a result, there's not necessarily a single thing to merge the metadata with. I suppose merging everything (derived from one) with everything (derived from the other) might work, but in any event, it seems non-trivial. I'm happy to have someone revisit this if they find this needs to be more precise.
I agree. I removed this FIXME.


================
Comment at: lib/CodeGen/StackColoring.cpp:1005
+
+      // We adjust TBAA information for merged stack slots.
+      MachineSDNode::mmo_iterator MemOps =
----------------
hfinkel wrote:
> This is not specific to TBAA. You should replace TBAA with AA metadata in all of the comments.
Done.


================
Comment at: lib/CodeGen/StackColoring.cpp:1014
+        // may share the same memory location.
+        bool MayModified = false;
+        if (MMO->getAAInfo().TBAA) {
----------------
hfinkel wrote:
> I don't understand this name. How about `MayHaveConflictingAAMD`?
Fixed.


================
Comment at: lib/CodeGen/StackColoring.cpp:1025
+                const AllocaInst *AI = dyn_cast_or_null<AllocaInst>(V);
+                if (AI && MergedAllocas.count(AI)) {
+                  MayModified = true;
----------------
MatzeB wrote:
> Is `MergedAllocas` changing here? Looks like you can move the check further up outside this loop.
We need to check each Value V (and hence AI) with MergedAllocas. So I do this check in the loop.


================
Comment at: lib/CodeGen/StackColoring.cpp:1034
+          // We eliminate information on TBAA from the existing AAInfo.
+          AAMDNodes NewAAInfo = AAMDNodes(nullptr, MMO->getAAInfo().Scope,
+                                          MMO->getAAInfo().NoAlias);
----------------
hfinkel wrote:
> This situation is not specific to TBAA. If affects all of the AA metadata. You'll need to unset it all.
Done.


https://reviews.llvm.org/D35907





More information about the llvm-commits mailing list