<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> In my experience, clang (unlike gcc) preserves the naive meaning of the </div><div dir="ltr">> source C code in dealing with padding in structs -- assignments of whole </div><div dir="ltr">> structs copy the padding while assignments to members of structs retain </div><div dir="ltr">> their old padding. The only exception I know is returning structs from </div><div dir="ltr">> functions, as was pointed by Greg Parker in </div><div dir="ltr">> <a href="https://twitter.com/gparker/status/1193996158768578561" target="_blank">https://twitter.com/gparker/status/1193996158768578561</a> .</div><div dir="ltr"><br></div><div dir="ltr">> OTOH it's not clear to me this has anything to do with the <div>> transformations of LLVM IR that you mentioned. Perhaps clang just </div><div>> doesn't emit any IR that could trigger those optimizations.</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div>I think the change suggested in the patch is still valid because we need it to explain the optimizations.</div><div><br></div><div>Juneyoung</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at 5:37 AM Alexander Cherepanov <<a href="mailto:ch3root@openwall.com" target="_blank">ch3root@openwall.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello Juneyoung,<br>
<br>
On 19/08/2020 18.55, Juneyoung Lee via llvm-dev wrote:<br>
>> Interesting topic. Is any such optimization reachable from C?<br>
 ><br>
> Yes, I think so - both PassBuilder and PassManagerBuilder add MemCpyOpt &<br>
> IPSCCP in the default pass pipeline.<br>
<br>
In my experience, clang (unlike gcc) preserves the naive meaning of the <br>
source C code in dealing with padding in structs -- assignments of whole <br>
structs copy the padding while assignments to members of structs retain <br>
their old padding. The only exception I know is returning structs from <br>
functions, as was pointed by Greg Parker in <br>
<a href="https://twitter.com/gparker/status/1193996158768578561" rel="noreferrer" target="_blank">https://twitter.com/gparker/status/1193996158768578561</a> .<br>
<br>
I don't think this is required by any standard and it would be <br>
interesting to find out why exactly it's done this way (and whether the <br>
mentioned exception is a bug). This is especially wasteful in case of <br>
bit-fields.<br>
<br>
OTOH it's not clear to me this has anything to do with the <br>
transformations of LLVM IR that you mentioned. Perhaps clang just <br>
doesn't emit any IR that could trigger those optimizations.<br>
<br>
-- <br>
Alexander Cherepanov<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div>