On 7/2/20 12:09 PM, Hal Finkel via llvm-dev wrote: > > My general feeling is this: No optimizations should be creating > int2ptr/ptr2int. We really need to fix them all. They should use > pointer casts and i8* GEPs. This has, unfortunately, been a problem > for a long time. As Johannes says, optimizing int2ptr/ptr2int is very > tricky. In part, becaue all dependencies, including implicit control > dependencies, end up being part of the resulting aliasing based-on > chain, and we have a set of bug reports discussing this is great detail. > See, for example, https://bugs.llvm.org/show_bug.cgi?id=34548 Â -Hal > Â -Hal > > On 7/2/20 11:59 AM, Johannes Doerfert via llvm-dev wrote: >> >> Optimizing int2ptr + ptr2int (or vice versa) is tricky business. >> >> I would prefer it to be outside SROA, I think. >> >> >> We should be *very* careful and restrictive about it. >> >> My initial thought is that the pattern below can be optimized >> >> but I haven't spend too much time on it. >> >> >> ~ Johannes >> >> >> On 7/2/20 11:26 AM, Alexey Zhikhartsev via llvm-dev wrote: >>> Hi all, >>> >>> We noticed a lot of unnecessary ptrtoint instructions that stand in way of >>> some of our optimizations; the code pattern looks like this: >>> >>> bb1: >>> %int1 = ptrtoint %struct.s* %ptr1 to i64 >>> >>> bb2: >>> %int2 = ptrtoint %struct.s* %ptr2 to i64 >>> >>> %bb3: >>> %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] >>> %ptr = inttoptr i64 %phi.node to %struct.s* >>> >>> In short, the pattern above arises due to: >>> 1. InstCombine introducing a bitcast while performing a canonicalization in >>> combineLoadToOperationType() [1] >>> 2. GVN performing "load coercion" and replacing a load with a ptrtoint >>> (ptrtoint is due to the bitcast) >>> 3. SROA replacing store- and load-instructions with phi nodes. >>> >>> The question is: is it a good idea to clean ptrtoint/inttoptr instructions >>> inside SROA or should it be done higher in the pass pipeline? More details >>> below. >>> >>> The canonicalization in instruction combining is the root cause of the >>> problem, more information about the actual transformation and motivation >>> behind it can be found in this RFC [2]. Based on our experiments, getting >>> rid of the canonicalization reduces the number of ptrtoint instructions by >>> 16% and inttoptr instructions by 25%. However, it seems that overall, LLVM >>> benefits from the canonicalization and, at least back in 2015, many people >>> supported adding it to LLVM. So, I would like to find a way to keep it >>> while removing the ptrtoint-s that are unnecessary, and doing clean-up in >>> SROA is a straightforward way to achieve that. >>> >>> What does everybody think? >>> >>> Thanks, >>> Alexey >>> >>> [1] combineLoadToOperationType() >>> https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556 >>> [2] [LLVMdev] RFC: Missing canonicalization in LLVM >>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200702/73a044a6/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4