[Alignment][NFC] MaybeAlign in GVNExpression

[gchatelet]

Summary

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

[fhahn]

llvm/include/llvm/Transforms/Scalar/GVNExpression.h

326 ↗

(On Diff #221350)

This is wrapped in namespace llvm {. Is MaybeAlign ambiguous in this context?

[gchatelet]

• Address comments

[gchatelet]

llvm/include/llvm/Transforms/Scalar/GVNExpression.h

326 ↗

(On Diff #221350)

Indeed, Thx @fhahn.

[fhahn]

llvm/lib/Transforms/Scalar/NewGVN.cpp

1335 ↗

(On Diff #221964)

llvm:: should not be needed here either. I think in almost all contexts in llvm/, it should not be needed and probably should be removed in the patches already submitted as well.

[gchatelet]

• Address comments

[gchatelet]

llvm/lib/Transforms/Scalar/NewGVN.cpp

1335 ↗

(On Diff #221964)

I'll address this in a separate patch.

llvm/trunk/include/llvm/Transforms/Scalar/GVNExpression.h

void printInternal(raw_ostream &OS, bool PrintEType) const override {
     OS << " represents call at ";
     Call->printAsOperand(OS);
   }
 };
 
 class LoadExpression final : public MemoryExpression {
 private:
   LoadInst *Load;
-  unsigned Alignment;
+  MaybeAlign Alignment;
 
 public:
   LoadExpression(unsigned NumOperands, LoadInst *L,
                  const MemoryAccess *MemoryLeader)
       : LoadExpression(ET_Load, NumOperands, L, MemoryLeader) {}
 
   LoadExpression(enum ExpressionType EType, unsigned NumOperands, LoadInst *L,
                  const MemoryAccess *MemoryLeader)
       : MemoryExpression(NumOperands, EType, MemoryLeader), Load(L) {
-    Alignment = L ? L->getAlignment() : 0;
+    if (L)
+      Alignment = MaybeAlign(L->getAlignment());
   }
 
   LoadExpression() = delete;
   LoadExpression(const LoadExpression &) = delete;
   LoadExpression &operator=(const LoadExpression &) = delete;
   ~LoadExpression() override;
 
   static bool classof(const Expression *EB) {
     return EB->getExpressionType() == ET_Load;
   }
 
   LoadInst *getLoadInst() const { return Load; }
   void setLoadInst(LoadInst *L) { Load = L; }
 
-  unsigned getAlignment() const { return Alignment; }
-  void setAlignment(unsigned Align) { Alignment = Align; }
+  MaybeAlign getAlignment() const { return Alignment; }
+  void setAlignment(MaybeAlign Align) { Alignment = Align; }
 
   bool equals(const Expression &Other) const override;
   bool exactlyEquals(const Expression &Other) const override {
     return Expression::exactlyEquals(Other) &&
            cast<LoadExpression>(Other).getLoadInst() == getLoadInst();
   }
 
   // Debugging support

llvm/trunk/lib/Transforms/Scalar/NewGVN.cpp

auto *E =
       new (ExpressionAllocator) LoadExpression(1, LI, lookupMemoryLeader(MA));
   E->allocateOperands(ArgRecycler, ExpressionAllocator);
   E->setType(LoadType);
 
   // Give store and loads same opcode so they value number together.
   E->setOpcode(0);
   E->op_push_back(PointerOp);
   if (LI)
-    E->setAlignment(LI->getAlignment());
+    E->setAlignment(MaybeAlign(LI->getAlignment()));
 
   // TODO: Value number heap versions. We may be able to discover
   // things alias analysis can't on it's own (IE that a store and a
   // load have the same value, and thus, it isn't clobbering the load).
   return E;
 }
 
 const StoreExpression *