Depends on D54126.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 24587 Build 24586: arc lint + arc unit
Event Timeline
lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp | ||
---|---|---|
135–136 | I'm not too familiar with this disassembler part of the code, but the types with which Opc seem a bit confusing. So Opc is first declared above in auto Opc = nextByte(Bytes, Size); It is auto, but I guess because nextByte reutrns int, that's gonna be an int type. And nextByte takes uint8_t array but returns an int. Now the same variable Opc is used to store the return type of decodeULEB128 whose return type is uint64_t. I know I'm talking about both something pre-existing and things added in this CL, but do you think it would make more sense to change the return type of nextByte to uint8_t too and split the two Opcs, and maybe not make them auto? |
llvm/trunk/lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp | ||
---|---|---|
141 ↗ | (On Diff #173256) | wait.. the extension opcode is a LEB, yet has max 256 possible values? |
llvm/trunk/lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp | ||
---|---|---|
141 ↗ | (On Diff #173256) | This is true currently, which led me to open https://github.com/WebAssembly/simd/issues/46. However, in the future we might have more than 265 SIMD opcodes, in which case we could just bump WebAssemblyInstructionTableSize in the TableGen backend and have everything just work. This check just makes sure that bad input cannot cause us to read past the end of the disassembler tables. |
llvm/trunk/lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp | ||
---|---|---|
69 ↗ | (On Diff #173256) | Thanks for the heads up! I'll fix this soon. |
I'm not too familiar with this disassembler part of the code, but the types with which Opc seem a bit confusing. So Opc is first declared above in
It is auto, but I guess because nextByte reutrns int, that's gonna be an int type.
And nextByte takes uint8_t array but returns an int. Now the same variable Opc is used to store the return type of decodeULEB128 whose return type is uint64_t. I know I'm talking about both something pre-existing and things added in this CL, but do you think it would make more sense to change the return type of nextByte to uint8_t too and split the two Opcs, and maybe not make them auto?