llvm dev - Aug 2020 - The value of padding when storing an aggregate into memory

Hello Alexander,
> 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.

Juneyoung

On Wed, Aug 19, 2020 at 8:43 PM Alexander Cherepanov <ch3root at
openwall.com>
wrote:
> On 19/08/2020 06.05, Juneyoung Lee via llvm-dev wrote:
> > LangRef isn't clear about the value of padding when an aggregate
value is
> > stored into memory, and I'd like to suggest that storing an
aggregate
> fills
> > padding with undef.
> >
> > Here are a few clues that supports this change:
> >
> > - According to C17, the value of padding bytes when storing values in
> > structures or unions is unspecified.
> >
> > - IPSCCP ignores padding and directly stores a constant aggregate if
> > possible: https://godbolt.org/z/ddWq9z
> > Memcpyopt ignores padding when copying an aggregate or storing a
> constant:
> > https://godbolt.org/z/hY6ndd / https://godbolt.org/z/3WMP5a
>
> Interesting topic. Is any such optimization reachable from C?
>
> --
> 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/01ce2cb3/attachment.html>

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

> 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>