Optimization issues (Alias Analysis?)

Project Infrastructure LLVM Dev List Archives
1

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

2

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

3

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).

4

It’s not generally possible to know what happens, and it doesn’t happen often enough in cases where people want good performance to optimize.

One could build a constant lattice based tracker and try to do better, but …