[LLVMdev] types in load/store

[Jianzhou Zhao]

On Fri, Jul 9, 2010 at 3:44 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Jianzhou,
>
>> 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
>> object,
>> [...]
>> — 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,
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)
>
> LLVM does not have any such restrictions.
>
>> If LLVM IR is weaker than these C restrictions, then I have the
>> following questions about when GEP is undefined:
>
> In your examples, it is not GEP that would be undefined, but a load or
> store from the GEP.  GEP just offsets the memory address.  In C too it
> is not invalid to offset or cast a pointer; it is loading from or storing
> to the cast or offset pointer that may be invalid.
>
>> 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?
>
> Yes, except that as previously mentioned this is invalid for the i4 if
> the original value was not set by performing an i4 store.
>
> Since IR allows to define data layout of
>> targets (size and alignment for types), does whether such GEPs
>> undefined depend on its data layout?
>
> As I mentioned, there is no problem with GEPs being undefined.
>
>> 2) C allows characters as the least granularity when loading. Does
>> LLVM have the same assumption?
>
> LLVM doesn't have a notion of "character".  Currently all processors that LLVM
> targets are capable of addressing an octet (8 bits), but nothing smaller.  This
> means that the smallest granularity is currently i8.

Thanks. To understand how load/store work in LLVM, I looked into the
interpreter, where I found the target information is defined in
TargetData class, and aggregate types (like struct and array) compute
the correct padding and alignment from TargetData first before memory
access.

But I still run into one question, according to the code, the
visitLoad/visitStore functions used by the interpreter does not allow
accessing aggregate types, only simple types are legal.  On the other
hand, the GenericValue used by interpreter to store values in memory
only considers simple types (int, float, typ*) too, and each
'getOperandValue' also takes aggregate constants illegal when
converting them into GenericValue.

Actually my input *.ll files have load/store instructions on struct
(used in functions), which are taken as return values to ensure not to
be deleted. Interpreters (lli -force-interpreter ) can still
interpreter the code without any error/warning about meeting aggregate
values for memory accessing. I was wondering if lli (2.7) does any
transformation to flatten aggregate types into simple types, and split
such loads/stores into a sequence on primitive values.  Thanks.

>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Jianzhou