llvm dev - Oct 2012 - [LLVMdev] Target backend not converting char* to struct properly.

I'm having trouble getting my backend to properly treat the situation where
a char* is converted into a struct, i.e. something like:

char* pointer_representation = ...;
MyStruct* my_struct = (MyStruct*) pointer_representation;
my_struct->an_int_field = 5;

When this occurs, LLVM seems to fold the struct and char* into one assembly
'object', which is perfectly fine. However, it also keeps the
1-alignment
of the char array, which is not ok, as then the assignment (store) to the
'an_int_field' gets converted into a 4-byte aligned store instruction -
which of course fails when run.

My test case can be seen at http://pastebin.com/zPTi2GRW. Does anyone know
what I might need to do in my backend to make this work properly - perhaps
correct the definition of my 'store' instructions, or set a data-layout
for
a struct type somewhere?

Thanks,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121012/3f314a9b/attachment.html>

On Fri, Oct 12, 2012 at 10:43 AM, Stephen McGruer
<stephen.mcgruer at gmail.com> wrote:
> I'm having trouble getting my backend to properly treat the situation
where
> a char* is converted into a struct, i.e. something like:
>
> char* pointer_representation = ...;
> MyStruct* my_struct = (MyStruct*) pointer_representation;
> my_struct->an_int_field = 5;
>
> When this occurs, LLVM seems to fold the struct and char* into one assembly
> 'object', which is perfectly fine. However, it also keeps the
1-alignment of
> the char array, which is not ok, as then the assignment (store) to the
> 'an_int_field' gets converted into a 4-byte aligned store
instruction -
> which of course fails when run.
>
> My test case can be seen at http://pastebin.com/zPTi2GRW. Does anyone know
> what I might need to do in my backend to make this work properly - perhaps
> correct the definition of my 'store' instructions, or set a
data-layout for
> a struct type somewhere?
Your code has undefined behavior; you're just getting lucky if it
works anywhere.  (I can look up the standard reference if you're
interested.)  Try __attribute((aligned)) on the array.

-Eli

If you could point me towards the correct location in the standard I would
appreciate that - I didn't realize it wasn't acceptable to turn
pointer-data to structs. My example is reduced from the EEMBC benchmarks
where I ran into the problem, so I may have reduced it too far by accident
(but I'm fairly sure they do not use __attribute__ or similar).

Adding a __attribute__((aligned(...))) to my example did help, so thank you
for that! Now to determine what to do about EEMBC...

Thanks,
Stephen

On 12 October 2012 21:01, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Fri, Oct 12, 2012 at 10:43 AM, Stephen McGruer
> <stephen.mcgruer at gmail.com> wrote:
> > I'm having trouble getting my backend to properly treat the
situation
> where
> > a char* is converted into a struct, i.e. something like:
> >
> > char* pointer_representation = ...;
> > MyStruct* my_struct = (MyStruct*) pointer_representation;
> > my_struct->an_int_field = 5;
> >
> > When this occurs, LLVM seems to fold the struct and char* into one
> assembly
> > 'object', which is perfectly fine. However, it also keeps the
> 1-alignment of
> > the char array, which is not ok, as then the assignment (store) to the
> > 'an_int_field' gets converted into a 4-byte aligned store
instruction -
> > which of course fails when run.
> >
> > My test case can be seen at http://pastebin.com/zPTi2GRW. Does anyone
> know
> > what I might need to do in my backend to make this work properly -
> perhaps
> > correct the definition of my 'store' instructions, or set a
data-layout
> for
> > a struct type somewhere?
>
> Your code has undefined behavior; you're just getting lucky if it
> works anywhere.  (I can look up the standard reference if you're
> interested.)  Try __attribute((aligned)) on the array.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121012/3b5742ee/attachment.html>