Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
14495008:
Create type IDs based on reference counts. (Closed)
|
Created:
7 years, 7 months ago by Karl Modified:
7 years, 4 months ago CC:
native-client-reviews_googlegroups.com Base URL:
http://git.chromium.org/native_client/pnacl-llvm.git@master Visibility:
Public. |
DescriptionCreate type IDs based on reference counts.
Create type IDs based on number of references, rather than first reached.
This is done so that fewer bits are used to encode types that are commonly
used.
Note that this cuts the size of the generate bitcode file by about 1.5%, with
no effect on the reader, since it only changes the order type ID's are created.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3405
R=jvoung@chromium.org
Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-llvm.git;a=commit;h=1046c28
Patch Set 1 #
Total comments: 22
Patch Set 2 : #
Total comments: 13
Patch Set 3 : Fix issues raised and add test case. #Patch Set 4 : Fix typo in comment. #
Total comments: 4
Patch Set 5 : More fixes. #
Total comments: 4
Patch Set 6 : Fix typo in struct-types.ll #
Messages
Total messages: 13 (0 generated)
Please take a look at this CL. Thanks.
still looking through this... rough comments https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:36: TypeCountMap = new TypeCountMapType(); see question about whether this really needs to be a pointer? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:149: FirstFloatTypeID = TypeMap.size(); why can't FirstFloatTypeID just be a local variable? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:419: // (2) In this phase, TypeCountMap==NUll. We are registering types based on NUll -> NULL https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:421: // the other two contextx) we are inserting the minimal (implicitly) contextx -> contexts https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:434: bool EnumerateSubtypes = true; move variable decl to under the comment about "If in the second phase... " ? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:444: if (StructType *STy = dyn_cast<StructType>(Ty)) Is this really supposed to be "Ty" in both casts? How can "Ty" be both a PointerType and a StructType? Don't you need to get the pointed-to-type from PTy? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h (right): https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:54: TypeCountMapType* TypeCountMap; Does this need to be a pointer, or could it be allocated as part of the ValueEnumerator, like TypeMap, ValueMap, etc.? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:95: unsigned FirstFloatTypeID; why are float types singled out? https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:165: void OptimizeTypes(const Module *M); This seems like a change that could be upstreamed. It's not actually changing the wireformat, just optimizing the choice of IDs? I'll review this, but just saying that if we upstream, it could reduce the number of differences.
https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:151: EnumerateType(Type::getHalfTy(M->getContext())); half types are not allowed in the pnacl ABI. so if we go upstream this should probably stay, but otherwise it can go. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:420: // frequency. To miniize type IDs for frequently used types, (unlike miniize->minimize
Also updated the dumping of types to use a VBR field if a large number of types. This shrinks the bitcode files a little bit more, if the bitcode file references a lot of types. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:36: TypeCountMap = new TypeCountMapType(); On 2013/04/29 18:35:42, jvoung (cr) wrote: > see question about whether this really needs to be a pointer? As mentioned in the header file, this is only needed during initial collection, and therefore can be removed once the initial assignment to type ID's is done. I didn't see an easy way to pass this local collector through method calls, and guarantee that they are right. So I didn't make it a method argument, but a field on the enumerator class. However, since the scope of this is within this routine, I'm changing it to use a local instead of a new. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:149: FirstFloatTypeID = TypeMap.size(); On 2013/04/29 18:35:42, jvoung (cr) wrote: > why can't FirstFloatTypeID just be a local variable? Removed, since we don't use value yet. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:151: EnumerateType(Type::getHalfTy(M->getContext())); On 2013/04/29 19:38:42, Derek Schuff wrote: > half types are not allowed in the pnacl ABI. so if we go upstream this should > probably stay, but otherwise it can go. Note: Since these types are specific to NaCl, I will drop half type. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:419: // (2) In this phase, TypeCountMap==NUll. We are registering types based on On 2013/04/29 18:35:42, jvoung (cr) wrote: > NUll -> NULL Done. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:420: // frequency. To miniize type IDs for frequently used types, (unlike On 2013/04/29 19:38:42, Derek Schuff wrote: > miniize->minimize Done. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:421: // the other two contextx) we are inserting the minimal (implicitly) On 2013/04/29 18:35:42, jvoung (cr) wrote: > contextx -> contexts Done. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:434: bool EnumerateSubtypes = true; On 2013/04/29 18:35:42, jvoung (cr) wrote: > move variable decl to under the comment about "If in the second phase... " ? Done. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:444: if (StructType *STy = dyn_cast<StructType>(Ty)) On 2013/04/29 18:35:42, jvoung (cr) wrote: > Is this really supposed to be "Ty" in both casts? How can "Ty" be both a > PointerType and a StructType? Don't you need to get the pointed-to-type from > PTy? Good point. Fixing. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h (right): https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:54: TypeCountMapType* TypeCountMap; On 2013/04/29 18:35:42, jvoung (cr) wrote: > Does this need to be a pointer, or could it be allocated as part of the > ValueEnumerator, like TypeMap, ValueMap, etc.? I did it this way because it is only needed during the first pass of the construction of the type ID map. Once built, this space is wasted and should be collected. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:95: unsigned FirstFloatTypeID; On 2013/04/29 18:35:42, jvoung (cr) wrote: > why are float types singled out? I was looking ahead to "float" operations, which can subtract this value from the type id. However, since I'm not adding that, I will remove it until it is needed. https://codereview.chromium.org/14495008/diff/1/lib/Bitcode/NaCl/Writer/NaClV... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.h:165: void OptimizeTypes(const Module *M); On 2013/04/29 18:35:42, jvoung (cr) wrote: > This seems like a change that could be upstreamed. It's not actually changing > the wireformat, just optimizing the choice of IDs? > > I'll review this, but just saying that if we upstream, it could reduce the > number of differences. I agree that it is worth considering upstreaming this change.
Ping?
https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:40: TypeCountMap = &count_map; it's weird having this extra pointer and having NULL be a special meaning, when the structure itself is also local. Just use the local structure directly, and instead of having a NULL pointer, just use a boolean with a more helpful name.
https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp:239: // a large number of types. What is a large number of types, and on which benchmarks? There was one issue before where our var-args expansion pass was making up a whole bunch of duplicate types for the var-args buffers, but that should be gone after LLVM rev 1174111 (git hash). Then there is the plan to get rid of a bunch of struct types... Still, I guess if it does happen to be that the # of types is large, then with the sorting this should help... https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:146: EnumerateType(Type::getInt8Ty(M->getContext())); So these primitive types weren't already part of the TypeCountMap? It would be nice if they were automatically tracked also, then we wouldn't have to worry about remembering to add the "half" type or not. It would just have a count of 0 if the program never had any "half" types. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:442: // use up unnecessary (small) ID values just to define the pointer. Is there a test that would demonstrate this waste vs savings, to make sure that this is working? https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:446: if (StructType *STy = dyn_cast<StructType>(PTy)) Unless I'm reading this wrong, it still seems like it isn't possible to enter this branch and set EnumerateSubtypes to false. You're just casting Ty -> PTy -> STy, and it's all the same value, right? If you wanted the pointed-to-value's Type, you would need to cast PTy->getElementType(), instead of PTy?
PTAL. I fixed issues brought up, and added an LLVM test to show that we reorganize types based on frequency. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp:239: // a large number of types. On 2013/05/02 16:35:40, jvoung (cr) wrote: > What is a large number of types, and on which benchmarks? > > There was one issue before where our var-args expansion pass was making up a > whole bunch of duplicate types for the var-args buffers, but that should be gone > after LLVM rev 1174111 (git hash). Then there is the plan to get rid of a bunch > of struct types... > > Still, I guess if it does happen to be that the # of types is large, then with > the sorting this should help... > I thought this is still worth adding, in that while we currently are trying to get structure types out, this may change. Since the cost is minimal if there are a small number of types, and certainly helps if there are a large number of types, I didn't see why not to add this. As far as benchmarks, I'll clarify this by relating it to the bitcode file size for pnacl-translate.pexe. Changed comment to reflect this. I also agree that this should be up-streamed. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:40: TypeCountMap = &count_map; On 2013/05/02 15:41:45, Derek Schuff wrote: > it's weird having this extra pointer and having NULL be a special meaning, when > the structure itself is also local. Just use the local structure directly, and > instead of having a NULL pointer, just use a boolean with a more helpful name. The point wasn't just that it is NULL, but that it is referenced nonlocally through method calls. As such, it needs to be a field. Added a comment to try and explain this. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:146: EnumerateType(Type::getInt8Ty(M->getContext())); On 2013/05/02 16:35:40, jvoung (cr) wrote: > So these primitive types weren't already part of the TypeCountMap? It would be > nice if they were automatically tracked also, then we wouldn't have to worry > about remembering to add the "half" type or not. It would just have a count of > 0 if the program never had any "half" types. Reasonable point. Restructured code to make sure we only add the type if it is used. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:442: // use up unnecessary (small) ID values just to define the pointer. On 2013/05/02 16:35:40, jvoung (cr) wrote: > Is there a test that would demonstrate this waste vs savings, to make sure that > this is working? Ok. Done. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:446: if (StructType *STy = dyn_cast<StructType>(PTy)) On 2013/05/02 16:35:40, jvoung (cr) wrote: > Unless I'm reading this wrong, it still seems like it isn't possible to enter > this branch and set EnumerateSubtypes to false. > Your right. I fixed it. It definitely wasn't firing (you can easily see the savings with pnacl_translate.pexe). > You're just casting Ty -> PTy -> STy, and it's all the same value, right? If > you wanted the pointed-to-value's Type, you would need to cast > PTy->getElementType(), instead of PTy?
https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClBitcodeWriter.cpp:239: // a large number of types. On 2013/05/15 20:12:20, Karl wrote: > On 2013/05/02 16:35:40, jvoung (cr) wrote: > > What is a large number of types, and on which benchmarks? > > > > There was one issue before where our var-args expansion pass was making up a > > whole bunch of duplicate types for the var-args buffers, but that should be > gone > > after LLVM rev 1174111 (git hash). Then there is the plan to get rid of a > bunch > > of struct types... > > > > Still, I guess if it does happen to be that the # of types is large, then with > > the sorting this should help... > > > > I thought this is still worth adding, in that while we currently are trying to > get structure types out, this may change. Since the cost is minimal if there are > a small number of types, and certainly helps if there are a large number of > types, I didn't see why not to add this. > > As far as benchmarks, I'll clarify this by relating it to the bitcode file size > for pnacl-translate.pexe. Changed comment to reflect this. > > I also agree that this should be up-streamed. Yeah, it would be more useful for upstream users. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:146: EnumerateType(Type::getInt8Ty(M->getContext())); On 2013/05/15 20:12:20, Karl wrote: > On 2013/05/02 16:35:40, jvoung (cr) wrote: > > So these primitive types weren't already part of the TypeCountMap? It would > be > > nice if they were automatically tracked also, then we wouldn't have to worry > > about remembering to add the "half" type or not. It would just have a count > of > > 0 if the program never had any "half" types. > > Reasonable point. Restructured code to make sure we only add the type if it is > used. Do they not get counted in the type_counts then? If so, I don't see why they need to be given put ahead of the other types. The sorting would fall out naturally from the type_counts map? E.g., what if i16 is actually rare compared to i32, why should i16 come first (even though, yes the order of the first N types probably doesn't matter so much)? It's more about having less special code. https://codereview.chromium.org/14495008/diff/17001/lib/Bitcode/NaCl/Writer/N... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/17001/lib/Bitcode/NaCl/Writer/N... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:36: // Create map for counting frequency of types, and set feild feild -> field https://codereview.chromium.org/14495008/diff/17001/test/NaCl/Bitcode/struct-... File test/NaCl/Bitcode/struct-types.ll (right): https://codereview.chromium.org/14495008/diff/17001/test/NaCl/Bitcode/struct-... test/NaCl/Bitcode/struct-types.ll:8: %0 = type {i8} How come %0 isn't on line 7 and %1 on line 8? I guess I was imagining you would have: %typeA = ... %typeB = ... %typeC = type {%typeA *, %typeB *} %typeD = ... and have the ranking be: typeC is most used typeD is next most used typeA and typeB are not used directly. then that would test that you don't recurse into typeC and start putting typeA and typeB before typeD.
PTAL. Thanks. https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/6001/lib/Bitcode/NaCl/Writer/Na... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:146: EnumerateType(Type::getInt8Ty(M->getContext())); On 2013/05/15 21:01:36, jvoung (cr) wrote: > On 2013/05/15 20:12:20, Karl wrote: > > On 2013/05/02 16:35:40, jvoung (cr) wrote: > > > So these primitive types weren't already part of the TypeCountMap? It would > > be > > > nice if they were automatically tracked also, then we wouldn't have to worry > > > about remembering to add the "half" type or not. It would just have a count > > of > > > 0 if the program never had any "half" types. > > > > Reasonable point. Restructured code to make sure we only add the type if it is > > used. > > Do they not get counted in the type_counts then? If so, I don't see why they > need to be given put ahead of the other types. The sorting would fall out > naturally from the type_counts map? > > E.g., what if i16 is actually rare compared to i32, why should i16 come first > (even though, yes the order of the first N types probably doesn't matter so > much)? > > It's more about having less special code. The point of explicitly ordering was to (in the future) shrink the bit width needed for integer/floating point operations. I may be presuming too much here. Not to presume, I'll remove this until I'm actually ready to change binary integer/floating operations. That way, I'll have a better feel for whether this is a good assumption. https://codereview.chromium.org/14495008/diff/17001/lib/Bitcode/NaCl/Writer/N... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/17001/lib/Bitcode/NaCl/Writer/N... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:36: // Create map for counting frequency of types, and set feild On 2013/05/15 21:01:36, jvoung (cr) wrote: > feild -> field Done. https://codereview.chromium.org/14495008/diff/17001/test/NaCl/Bitcode/struct-... File test/NaCl/Bitcode/struct-types.ll (right): https://codereview.chromium.org/14495008/diff/17001/test/NaCl/Bitcode/struct-... test/NaCl/Bitcode/struct-types.ll:8: %0 = type {i8} On 2013/05/15 21:01:36, jvoung (cr) wrote: > How come %0 isn't on line 7 and %1 on line 8? > > I guess I was imagining you would have: > > %typeA = ... > %typeB = ... > %typeC = type {%typeA *, %typeB *} > %typeD = ... > > and have the ranking be: > > typeC is most used > typeD is next most used > typeA and typeB are not used directly. > > then that would test that you don't recurse into typeC and start putting typeA > and typeB before typeD. > I created a more complicated example. Hope this is what you are looking for. https://codereview.chromium.org/14495008/diff/25001/lib/Bitcode/NaCl/Writer/N... File lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp (right): https://codereview.chromium.org/14495008/diff/25001/lib/Bitcode/NaCl/Writer/N... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:133: // construction is repeatable. Changed the type of TypeSetType to be on unsigned, and stored the generated index for each type. Did this so that type order is repeatable. https://codereview.chromium.org/14495008/diff/25001/lib/Bitcode/NaCl/Writer/N... lib/Bitcode/NaCl/Writer/NaClValueEnumerator.cpp:137: TypeList IdType(Types); Also added this so that we can look up types from type ids.
LGTM -- can you update the commit message about the primitive types too? https://codereview.chromium.org/14495008/diff/25001/test/NaCl/Bitcode/struct-... File test/NaCl/Bitcode/struct-types.ll (right): https://codereview.chromium.org/14495008/diff/25001/test/NaCl/Bitcode/struct-... test/NaCl/Bitcode/struct-types.ll:28: ; i6 i6 -> i16
Fixed commit message and pushing. https://codereview.chromium.org/14495008/diff/25001/test/NaCl/Bitcode/struct-... File test/NaCl/Bitcode/struct-types.ll (right): https://codereview.chromium.org/14495008/diff/25001/test/NaCl/Bitcode/struct-... test/NaCl/Bitcode/struct-types.ll:28: ; i6 On 2013/05/20 22:39:36, jvoung (cr) wrote: > i6 -> i16 Done.
Message was sent while issue was closed.
Committed patchset #6 manually as r1046c28 (presubmit successful). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
