thr3ads.net - llvm dev - [llvm-dev] Optimization Problem [Apr 2019]

If this information is useful, please help other people find it:
Share via:

Garba Peter via llvm-dev

2019-Apr-27 11:27 UTC

[llvm-dev] Optimization Problem

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190427/833c6f92/attachment.html>

Doerfert, Johannes via llvm-dev

2019-Apr-27 19:54 UTC

head link

[llvm-dev] Optimization Problem

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:
  http://llvm.1065342.n5.nabble.com/GEP-vs-IntToPtr-PtrToInt-td44587.html
 
http://llvm.1065342.n5.nabble.com/Canonicalization-of-ptrtoint-inttoptr-and-getelementptr-td72015.html
  https://reviews.llvm.org/D37419#860016

There are also good talks (and papers) about the topic:
  https://www.youtube.com/watch?v=CPokKMqAVdY
  https://www.youtube.com/watch?v=r0XVS4Atl3U

Enabling more transformations in their presence, e.g.,
  https://reviews.llvm.org/D9152
often caused problems:
 
https://github.com/llvm-mirror/llvm/commit/185966c6502046ad33f3fb64d70b4ef3c7e8faa3

I know I didn't actually answer your questions, but I hope this might
still help.

Cheers,
  Johannes

On 04/27, Garba Peter via llvm-dev wrote:> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190427/d92e93c2/attachment.sig>

Finkel, Hal J. via llvm-dev

2019-Apr-29 12:46 UTC

head link

[llvm-dev] Optimization Problem

On 4/27/19 2:54 PM, Doerfert, Johannes via llvm-dev wrote:

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:
  http://llvm.1065342.n5.nabble.com/GEP-vs-IntToPtr-PtrToInt-td44587.html
 
http://llvm.1065342.n5.nabble.com/Canonicalization-of-ptrtoint-inttoptr-and-getelementptr-td72015.html
  https://reviews.llvm.org/D37419#860016

There are also good talks (and papers) about the topic:
  https://www.youtube.com/watch?v=CPokKMqAVdY
  https://www.youtube.com/watch?v=r0XVS4Atl3U

Enabling more transformations in their presence, e.g.,
  https://reviews.llvm.org/D9152
often caused problems:
 
https://github.com/llvm-mirror/llvm/commit/185966c6502046ad33f3fb64d70b4ef3c7e8faa3

I know I didn't actually answer your questions, but I hope this might
still help.


To add to this quickly:

 1. There are theoretical issues with tracking dependencies through integer
casts (see, e.g., https://bugs.llvm.org/show_bug.cgi?id=34548 and
https://reviews.llvm.org/D59065).

 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.

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.

 -Hal




Cheers,
  Johannes

On 04/27, Garba Peter via llvm-dev wrote:


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.





_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto: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<mailto: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/20190429/c56e6e10/attachment.html>

Possibly Parallel Threads

Search for more reasonably related threads

llvm dev - Apr 2019 - Optimization Problem

[llvm-dev] Optimization Problem

[llvm-dev] Optimization Problem

[llvm-dev] Optimization Problem

Possibly Parallel Threads