Changed the structure of the generated IR to make it easier to vectorize
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 21163 Build 21163: arc lint + arc unit
Event Timeline
clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp | ||
---|---|---|
134 | It's probably generating pc since I'm using my desktop. I'll change it to unknown so it's not platform-specific. | |
135 | It doesn't, I just thought it was cleaner and produced slightly smaller IR. It also more closely mimics the behavior of the -emit-llvm flag. | |
138 | Same answer as above. Should I change these back? |
clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp | ||
---|---|---|
138 | I think the previous labels were more human-readable. |
clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp | ||
---|---|---|
127 | Should %s be signed? Do we want unsigned compare here? | |
134 | Seems like the endloop label is unnecessary. Does this help vectorize? If not, lets get rid of unconditional jumps to the next line. | |
136–138 | This will make overflow undefined... Isn't that the opposite of what we want? That will permit LLVM to assume overflow never happens and modify the code in new ways based on that assumption. |
clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp | ||
---|---|---|
127 | I don't think it matters since %s will always be positive (it will always be equal to | |
134 | I initially had it this way since that's how -emit-llvm generated the code. But it doesn't seem like it's necessary for loops to be vectorized upon further inspection. | |
136–138 | That's a good point. It probably won't matter since this addition will never overflow (we're just starting at zero and incrementing by one). This is what was generated by -emit-llvm. I'll remove it to reduce confusion. |
Should %s be signed? Do we want unsigned compare here?