[LLVMdev] types in load/store

Jianzhou Zhao jianzhou at seas.upenn.edu
Thu Jul 8 16:23:14 PDT 2010

On Thu, Jul 8, 2010 at 11:09 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> Hi,
> I have a confusion about types used in load/store,
> (http://llvm.org/docs/GetElementPtr.html#types) says that [...]
> Furthermore, loads and stores don't have to use the same types as the
> type of the underlying object. Types in this context serve only to
> specify memory size and alignment. Beyond that there are merely a hint
> to the optimizer indicating how the value will likely be used. [...]
> I was wondering that in which cases we may have undefined behaviors if
> types in load/store don't match the objects'. In C, they need to be
> compatible, which means the size of types should be same, otherwise
> undefined. Do we follow the same convention in LLVM IR? Does GEP also
> follow similar rules when types mismatch?

I misunderstood C99 ISO, such behaviors are defined not when types
have the same sizes, but when they are same (compatible)  types with
signed or qualified extension (this is much stronger than being of
same sizes), or reading char by char:

7 An object shall have its stored value accessed only by an lvalue
expression that has one of
the following types:
— a type compatible with the effective type of the object,
— a type that is the signed or unsigned type corresponding to the
effective type of the
— an aggregate or union type that includes one of the aforementioned
types among its
members (including, recursively, a member of a subaggregate or
contained union), or
— a character type.
(sec 6.5, items 6 and 7, page 67-68,

If LLVM IR is weaker than these C restrictions, then I have the
following questions about when GEP is undefined:
1) Can I load a value partially or overlapped with other stored
values? For example, if the stored values are of type [10*i32], and we
cast i32* to  {i8, i4, float} *,  can we successfully load each fields
via the addresses from GEPs? Since IR allows to define data layout of
targets (size and alignment for types), does whether such GEPs
undefined depend on its data layout?

2) C allows characters as the least granularity when loading. Does
LLVM have the same assumption?

> The other question is about 'when loading a value of a type like i20
> with a size that is not an integral number of bytes, the result is
> undefined if the value was not originally written using a store of the
> same type'. At this case, can we make an assumption that typically we
> only load the 20 bits, but ignore extra bits, like what store does at
> such a case. Is there any problem that stops such an assumption?
> Thanks.
> --
> Jianzhou


More information about the llvm-dev mailing list