[PATCH] D18662: [GVN] Fix handling of sub-byte types in big-endian mode
Chandler Carruth via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 7 01:22:15 PDT 2016
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
Very nice fix. Minor complaints below about variable naming, feel free to address and commit as you see fit.
================
Comment at: lib/Transforms/Scalar/GVN.cpp:778
@@ -777,3 +777,5 @@
if (DL.isBigEndian()) {
- StoredVal = IRB.CreateLShr(StoredVal, StoreSize - LoadSize, "tmp");
}
----------------
You know, "StoreSize" and "LoadSize" are really bad variable names since they aren't actually the type store size... Which makes much more sense out of how this bug got in there in the first place.
Maybe rename them (in a separate patch) to something more clearly to do with value sizes rather than store and load sizes?
================
Comment at: lib/Transforms/Scalar/GVN.cpp:1061
@@ -1058,4 +1060,3 @@
if (DL.isBigEndian())
- RV = Builder.CreateLShr(RV,
- NewLoadSize*8-SrcVal->getType()->getPrimitiveSizeInBits());
+ RV = Builder.CreateLShr(RV, (NewLoadSize - SrcValSize) * 8);
RV = Builder.CreateTrunc(RV, SrcVal->getType());
----------------
Here, we see the reverse confusion IMO: SrcValSize would be better named SrcValStoreSize.
http://reviews.llvm.org/D18662
More information about the llvm-commits
mailing list