fhahn added a comment. In D116935#3232763 <https://reviews.llvm.org/D116935#3232763>, @craig.topper wrote:
> Do the programs in compile-time tracker make much use of bitfields? I'd expect some bitfields, but nothing excessive/pathological. > Is there any indication in rdar://7362516 what program needed this? It looks > like assigning a bitfield to 0 is enough to generate an or with 0 that > survives through fast isel at -O0 on X86. But a few assignments to 0 wouldn't > make for a huge problem, so I imagine there must have been something > pathological about some program. I had a look at rdar://7362516 and there is nothing in the issue & history that seems to indicate that the motivation was a pathological case, but just a very simple struct with 4 bitfields. Clang generates a lot of other redundant IR that doesn't get folded by IRBuilder (e.g. add or shifts of 0), which survive in a similar way with fast isel. AFAICT there's nothing that would indicate that `or X, 0` is a special case that would warrant special treatment. rdar://7362516 also mentions that IRBuilder should fold shifts with 0 as well, but it looks like that's not happening at the moment either. I am inclined to remove the special case from IRBuilder, which applies the 'IRBuilder should not optimize directly, only via a specified folder' policy also to `CreateOr`. I don't think we should use InstSimplifyFolder in Clang, because Clang usually doesn't try very hard to optimize IR and InstructionSimplify provides a lot of folds. But if we get additional feedback after the commit that the `or X, 0` fold is very valuable for Clang, this can be provided to Clang via a custom ClangFolder. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116935/new/ https://reviews.llvm.org/D116935 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
