llvm dev - Jul 2016 - Optimization issues (Alias Analysis?)

Hey,

I am currently working on a VM which is based on LLVM and I would like to
use its optimizer, but it somehow it can't detect something very simple (I
guess.)

This is the LLVM IR:

target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
target triple = "i386-unknown-linux-gnu"

%struct.regs = type { i32, i32, i32 }

define void @Test(%struct.regs* noalias nocapture sret, i32, i32, i32)
local_unnamed_addr #0 {
  %5 = add i32 %3, -4
  %6 = inttoptr i32 %5 to i32*
  store i32 %2, i32* %6, align 4

  %7 = add i32 %3, -8
  %8 = inttoptr i32 %7 to i32*
  store i32 %1, i32* %8, align 4

  %9 = load i32, i32* %6, align 4

  %.sroa.0.0..sroa_idx = getelementptr inbounds %struct.regs, %struct.regs*
%0, i32 0, i32 0
  store i32 %9, i32* %.sroa.0.0..sroa_idx, align 4

  %.sroa.4.0..sroa_idx4 = getelementptr inbounds %struct.regs,
%struct.regs* %0, i32 0, i32 1
  store i32 %1, i32* %.sroa.4.0..sroa_idx4, align 4

  %.sroa.7.0..sroa_idx5 = getelementptr inbounds %struct.regs,
%struct.regs* %0, i32 0, i32 2
  store i32 %3, i32* %.sroa.7.0..sroa_idx5, align 4

  ret void
}

This is compiled from some cpp just to reproduce the issue.
The issue here is that the load isn't eliminated and that the third store
isn't directly using %2.

I thought that this might be an issue with the current BasicAliasAnalysis
so I also tried CFL which isn't working either.

~ Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160704/f8fe973b/attachment.html>

Hi Nick, 

We really don't do AA on inttoptr at all. You should use i8* (or some other
appropriate pointer type) and GEPs instead.

-Hal 

----- Original Message -----
> From: "Peet Nick via llvm-dev" <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Monday, July 4, 2016 11:05:11 AM
> Subject: [llvm-dev] Optimization issues (Alias Analysis?)
> Hey,
> I am currently working on a VM which is based on LLVM and I would
> like to use its optimizer, but it somehow it can't detect something
> very simple (I guess.)
> This is the LLVM IR:
> target datalayout =
"e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
> target triple = "i386-unknown-linux-gnu"
> %struct.regs = type { i32, i32, i32 }
> define void @Test(%struct.regs* noalias nocapture sret, i32, i32,
> i32) local_unnamed_addr #0 {
> %5 = add i32 %3, -4
> %6 = inttoptr i32 %5 to i32*
> store i32 %2, i32* %6, align 4
> %7 = add i32 %3, -8
> %8 = inttoptr i32 %7 to i32*
> store i32 %1, i32* %8, align 4
> %9 = load i32, i32* %6, align 4
> %.sroa.0.0..sroa_idx = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 0
> store i32 %9, i32* %.sroa.0.0..sroa_idx, align 4
> %.sroa.4.0..sroa_idx4 = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 1
> store i32 %1, i32* %.sroa.4.0..sroa_idx4, align 4
> %.sroa.7.0..sroa_idx5 = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 2
> store i32 %3, i32* %.sroa.7.0..sroa_idx5, align 4
> ret void
> }
> This is compiled from some cpp just to reproduce the issue.
> The issue here is that the load isn't eliminated and that the third
> store isn't directly using %2.
> I thought that this might be an issue with the current
> BasicAliasAnalysis so I also tried CFL which isn't working either.
> ~ Nick
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160705/1d5c2582/attachment.html>

Oh, I understand.
Although I am quite curious why this isn't supported as in C it might be
very common to cast integer to pointers and back (This is what triggers
clang to emit inttoptr instructions).

On Tue, Jul 5, 2016 at 8:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> Hi Nick,
>
> We really don't do AA on inttoptr at all. You should use i8* (or some
> other appropriate pointer type) and GEPs instead.
>
>  -Hal
>
> ------------------------------
>
> *From: *"Peet Nick via llvm-dev" <llvm-dev at
lists.llvm.org>
> *To: *llvm-dev at lists.llvm.org
> *Sent: *Monday, July 4, 2016 11:05:11 AM
> *Subject: *[llvm-dev] Optimization issues (Alias Analysis?)
>
>
> Hey,
>
> I am currently working on a VM which is based on LLVM and I would like to
> use its optimizer, but it somehow it can't detect something very simple
(I
> guess.)
>
> This is the LLVM IR:
>
> target datalayout =
"e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
> target triple = "i386-unknown-linux-gnu"
>
> %struct.regs = type { i32, i32, i32 }
>
> define void @Test(%struct.regs* noalias nocapture sret, i32, i32, i32)
> local_unnamed_addr #0 {
>   %5 = add i32 %3, -4
>   %6 = inttoptr i32 %5 to i32*
>   store i32 %2, i32* %6, align 4
>
>   %7 = add i32 %3, -8
>   %8 = inttoptr i32 %7 to i32*
>   store i32 %1, i32* %8, align 4
>
>   %9 = load i32, i32* %6, align 4
>
>   %.sroa.0.0..sroa_idx = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 0
>   store i32 %9, i32* %.sroa.0.0..sroa_idx, align 4
>
>   %.sroa.4.0..sroa_idx4 = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 1
>   store i32 %1, i32* %.sroa.4.0..sroa_idx4, align 4
>
>   %.sroa.7.0..sroa_idx5 = getelementptr inbounds %struct.regs,
> %struct.regs* %0, i32 0, i32 2
>   store i32 %3, i32* %.sroa.7.0..sroa_idx5, align 4
>
>   ret void
> }
>
> This is compiled from some cpp just to reproduce the issue.
> The issue here is that the load isn't eliminated and that the third
store
> isn't directly using %2.
>
> I thought that this might be an issue with the current BasicAliasAnalysis
> so I also tried CFL which isn't working either.
>
> ~ Nick
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160705/4518e8e1/attachment.html>