[llvm-dev] The value of padding when storing an aggregate into memory

[Juneyoung Lee via llvm-dev]

> In my experience, clang (unlike gcc) preserves the naive meaning of the
> source C code in dealing with padding in structs -- assignments of whole
> structs copy the padding while assignments to members of structs retain
> their old padding. The only exception I know is returning structs from
> functions, as was pointed by Greg Parker in
> https://twitter.com/gparker/status/1193996158768578561 .

> OTOH it's not clear to me this has anything to do with the
> transformations of LLVM IR that you mentioned. Perhaps clang just
> doesn't emit any IR that could trigger those optimizations.

Thank you for the info. I also tried to find an example written in C that
leaves load/store of an aggregate, and I couldn't. Rather than directly
loading/storing aggregates, the lowered IR uses field-wise load/store or
memcpy/memmove of an aggregate.
I skimmed through unit tests in clang, and using pointers to
member functions might introduce load/store of aggregates since it uses a
pair of i32 or i64.
But (1) it isn't clear whether the member function pointer type has padding
(2) if padding exists, a valid c++ program can store data to it.

Until I find a working example, I have to say that the change is for
explaining the relevant optimizations in LLVM, even if the passes exist in
the pipeline.
I think the change suggested in the patch is still valid because we need it
to explain the optimizations.

Juneyoung

On Thu, Aug 20, 2020 at 5:37 AM Alexander Cherepanov <ch3root at openwall.com>
wrote:

> Hello Juneyoung,
>
> On 19/08/2020 18.55, Juneyoung Lee via llvm-dev wrote:
> >> Interesting topic. Is any such optimization reachable from C?
>  >
> > Yes, I think so - both PassBuilder and PassManagerBuilder add MemCpyOpt &
> > IPSCCP in the default pass pipeline.
>
> In my experience, clang (unlike gcc) preserves the naive meaning of the
> source C code in dealing with padding in structs -- assignments of whole
> structs copy the padding while assignments to members of structs retain
> their old padding. The only exception I know is returning structs from
> functions, as was pointed by Greg Parker in
> https://twitter.com/gparker/status/1193996158768578561 .
>
> I don't think this is required by any standard and it would be
> interesting to find out why exactly it's done this way (and whether the
> mentioned exception is a bug). This is especially wasteful in case of
> bit-fields.
>
> OTOH it's not clear to me this has anything to do with the
> transformations of LLVM IR that you mentioned. Perhaps clang just
> doesn't emit any IR that could trigger those optimizations.
>
> --
> Alexander Cherepanov
>


-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/c4ae4b37/attachment.html>