<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/2/20 12:09 PM, Hal Finkel via
llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:eeb90332-a713-5a2f-6ad3-ace1acc2150f@anl.gov">
<p>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.</p>
</blockquote>
<p><br>
</p>
<p>See, for example, <a class="moz-txt-link-freetext" href="https://bugs.llvm.org/show_bug.cgi?id=34548">https://bugs.llvm.org/show_bug.cgi?id=34548</a></p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:eeb90332-a713-5a2f-6ad3-ace1acc2150f@anl.gov">
<p> -Hal<br>
</p>
<div class="moz-cite-prefix">On 7/2/20 11:59 AM, Johannes Doerfert
via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:e5c4e503-4440-0e9e-8d63-7d2aab4ef5c9@gmail.com">
<p><font face="Hack Nerd Font Mono">Optimizing int2ptr + ptr2int
(or vice versa) is tricky business.</font></p>
<p><font face="Hack Nerd Font Mono">I would prefer it to be
outside SROA, I think.</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">We should be *very* careful
and restrictive about it.</font></p>
<p><font face="Hack Nerd Font Mono">My initial thought is that
the pattern below can be optimized</font></p>
<p><font face="Hack Nerd Font Mono">but I haven't spend too much
time on it.</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">~ Johannes<br>
</font></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/2/20 11:26 AM, Alexey
Zhikhartsev via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAOyMDRNvE3KF4QVgUNtXkq9C9vDFceZC05nFRvTLMm-oPskDzw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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()
<a class="moz-txt-link-freetext" href="https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556" moz-do-not-send="true">https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556</a>
[2] [LLVMdev] RFC: Missing canonicalization in LLVM
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html" moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>