[LLVMdev] BasicAliasAnalysis and out-of-bound GEP indices

[Wojciech Matyjewicz]

Hi,

Daniel Berlin wrote:
> Then the original reported code is fine, and the bug is in llvm or
> llvm-gc (IE Owen is wrong)

There is, actually, no problem with this example.
I attached it, because it contains some specific programming technique,
for which, after instcombining, a weird GEP is generated. I've pasted
fragments of generated assembly code below, if someone is interested.

These are the types declared in the code:

%struct.device = type opaque ; simplified
%struct.ehci_hcd = type opaque ; simplified
%struct.usb_bus = type { %struct.device* }
%struct.usb_hcd = type { %struct.usb_bus, [0 x i32] }

And this is are the interesting instructions. %hcd is a function
argument of type %struct.usb_hcd:

-= before instcombine =-
 ; based on some facts it is known the second field of
 ; structure pointed by %hcd is of type %struct.ehci_hcd
%tmp9 = getelementptr %struct.usb_hcd* %hcd, i32 0, i32 1
%tmp910 = bitcast [0 x i32]* %tmp9 to %struct.ehci_hcd*

 ; later in the source, a pointer to the parent struct is obtained
 ; from %tmp910 using inner field's offset knowledge
 ; (__builtin_offsetof operator in the C source)
%tmp1415 = bitcast %struct.ehci_hcd* %tmp910 to [0 x i32]*
%tmp1617 = bitcast [0 x i32]* %tmp1415 to i8*
%tmp18 = getelementptr i8* %tmp1617, i32 -4
%tmp1819 = bitcast i8* %tmp18 to %struct.usb_hcd*

-= after instcombine =-
%tmp18 = getelementptr %struct.usb_hcd* %hcd, i32 0, i32 1, i32 -1

%tmp1819 = bitcast i32* %tmp18 to %struct.usb_hcd*

It is an example of GEP instruction that, on purpose, crosses the bounds
of an inner field to reach a field from the outer structure. It seems to
be correct, assuming negative index is also allowed for a variable-sized
array. BasicAA is correct for in this case, as it seems to treat
conservatively any indexing of a variable-sized array.

--Wojtek