<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 4/27/19 2:54 PM, Doerfert, Johannes via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:20190427195409.GA1229@arch-linux-jd">
<pre class="moz-quote-pre" wrap="">Hi Peter,
In general, int2ptr/ptr2int open up a variety of issues. If you can,
avoid them in the first place and use GEPs, e.g., do your arithmetic on
char *.
I dug up a few posts that might help:
<a class="moz-txt-link-freetext" href="http://llvm.1065342.n5.nabble.com/GEP-vs-IntToPtr-PtrToInt-td44587.html">http://llvm.1065342.n5.nabble.com/GEP-vs-IntToPtr-PtrToInt-td44587.html</a>
<a class="moz-txt-link-freetext" href="http://llvm.1065342.n5.nabble.com/Canonicalization-of-ptrtoint-inttoptr-and-getelementptr-td72015.html">http://llvm.1065342.n5.nabble.com/Canonicalization-of-ptrtoint-inttoptr-and-getelementptr-td72015.html</a>
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D37419#860016">https://reviews.llvm.org/D37419#860016</a>
There are also good talks (and papers) about the topic:
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=CPokKMqAVdY">https://www.youtube.com/watch?v=CPokKMqAVdY</a>
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=r0XVS4Atl3U">https://www.youtube.com/watch?v=r0XVS4Atl3U</a>
Enabling more transformations in their presence, e.g.,
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D9152">https://reviews.llvm.org/D9152</a>
often caused problems:
<a class="moz-txt-link-freetext" href="https://github.com/llvm-mirror/llvm/commit/185966c6502046ad33f3fb64d70b4ef3c7e8faa3">https://github.com/llvm-mirror/llvm/commit/185966c6502046ad33f3fb64d70b4ef3c7e8faa3</a>
I know I didn't actually answer your questions, but I hope this might
still help.</pre>
</blockquote>
<p><br>
</p>
<p>To add to this quickly:</p>
<p> 1. There are theoretical issues with tracking dependencies through integer casts (see, e.g.,
<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> and <a href="https://reviews.llvm.org/D59065">
https://reviews.llvm.org/D59065</a>).</p>
<p> 2. In general, we don't wish to have code in AA to deal with integer arithmetic - we already need to have code which deals with arithmetic in the form of GEPs, and having very similar code to deal with the integer arithmetic in between ptrtoint/inttoptr
casts adds code complexity to AA with seemingly-minimal gain.<br>
</p>
<p>As Johannes says, cast to char* (or i8*, if you're generating IR directly) and do the arithmetic in that form. This is not just syntactic sugar for the casts + int arithmetic form, but gives the optimizer important semantic information.</p>
<p> -Hal</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:20190427195409.GA1229@arch-linux-jd">
<pre class="moz-quote-pre" wrap="">
Cheers,
Johannes
On 04/27, Garba Peter via llvm-dev wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi,
I try to understand why llvm can't optimize this small piece of code.
My expectation is that the IR will be optimized to a " ret i64 2101545.
But somehow the alias analysis fails when the pointer is casted to an integer value,
so the dead code eliminator can't optimize it away.
Could someone explain to me why this is failing and if there is a solution for that ?
I can trick the alias analysis by setting %5 to a concrete integer so the code can be optimized further,
but I'm still wondering why llvm can't do it.
Thanks,
Peter
define dso_local i64 @func(i64, i64, i64) local_unnamed_addr #0 {
.split:
%3 = alloca [100 x i64], align 16
%4 = getelementptr inbounds [100 x i64], [100 x i64]* %3, i64 0, i64 2
%5 = ptrtoint i64* %4 to i64
%6 = add i64 %5, -8
%7 = inttoptr i64 %6 to i64*
store i64 0, i64* %7, align 8
%8 = add i64 %5, -12
%9 = inttoptr i64 %8 to i32*
store i32 0, i32* %9, align 4
%10 = add i64 %5, -16
%11 = inttoptr i64 %10 to i32*
store i32 0, i32* %11, align 16
ret i64 2101545
}
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<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-quote-pre" wrap="">
</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>