[llvm-dev] Optimization issues (Alias Analysis?)

[Peet Nick via llvm-dev]

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>