<div dir="ltr"><div dir="ltr">On Wed, 21 Jul 2021 at 13:43, Han Zhu via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">After clang codegen, is the class layout final? Does the optimizer modify the class layout?</div></blockquote><div><br></div><div>LLVM IR does not contain enough information to determine whether the optimization is valid. The IR that we generate for:</div><div><br></div><div>struct S {<br> ~S() {}<br> int a;<br> int b;<br> char c;<br> // 3 bytes padding<br>};<br><br>unsigned copy_noalias(S* __restrict__ a, S* b, int n) {<br> for (int i = 0; i < n; i++) {<br> a[i] = b[i];<br> }<br> return sizeof(a[0]);<br>}<br></div><div><br></div><div>... would also be correct IR to generate for:</div><div><br></div><div>struct T : S {<br> char x, y, z; // stored in S's tail padding<br>};<br><br>unsigned copy_noalias2(T* __restrict__ a, T* b, int n) {<br> for (int i = 0; i < n; i++) {<br> (S&)a[i] = (S&)b[i];<br> }<br> return sizeof((S&)a[0]);<br>}<br></div><div><br></div><div>You'll need to generate some additional information from the frontend if you want to be able to do this. You could, in at least some cases, analyze the types and expressions involved and locally prove that you know the last few bytes are guaranteed to be padding, then generate !tbaa.struct metadata and attach it to the @llvm.memcpy call that the frontend emits.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 12:31 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">I suspect the transform you’re trying to do is more complicated than you’re making it out to be.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In general, if you have a class that isn’t “POD for the purpose of layout” (<a href="https://itanium-cxx-abi.github.io/cxx-abi/abi.html" target="_blank">https://itanium-cxx-abi.github.io/cxx-abi/abi.html</a>), derived classes can store data in the tail
padding. So the “padding” might contain data the program cares about. If you want to overwrite that space, you need to prove there isn’t a derived class storing data there.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Possible proof approaches:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<ol style="margin-top:0in" start="1" type="1">
<li style="margin-left:0in">If the class is marked “final”, there aren’t any derived classes.<u></u><u></u></li><li style="margin-left:0in">Array indexing with the wrong pointer type might be illegal.<u></u><u></u></li></ol>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Eli<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Han Zhu via cfe-dev<br>
<b>Sent:</b> Wednesday, July 21, 2021 11:46 AM<br>
<b>To:</b> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [EXT] [cfe-dev] How to tell if a class contains tail padding?<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi,<br>
<br>
I'm working on an optimization to improve LoopIdiomRecognize pass. For a trivial loop like this:<br>
<br>
```<br>
struct S {<br>
int a;<br>
int b;<br>
char c;<br>
// 3 bytes padding<br>
};<br>
<br>
unsigned copy_noalias(S* __restrict__ a, S* b, int n) {<br>
for (int i = 0; i < n; i++) {<br>
a[i] = b[i];<br>
}<br>
return sizeof(a[0]);<br>
}<br>
```<br>
<br>
Clang generates the below loop (some parts of IR omitted):<br>
```<br>
%struct.S = type { i32, i32, i8 }<br>
<br>
for.body: ; preds = %for.cond<br>
%2 = load %struct.S*, %struct.S** %b.addr, align 8<br>
%3 = load i32, i32* %i, align 4<br>
%idxprom = sext i32 %3 to i64<br>
%arrayidx = getelementptr inbounds %struct.S, %struct.S* %2, i64 %idxprom<br>
%4 = load %struct.S*, %struct.S** %a.addr, align 8<br>
%5 = load i32, i32* %i, align 4<br>
%idxprom1 = sext i32 %5 to i64<br>
%arrayidx2 = getelementptr inbounds %struct.S, %struct.S* %4, i64 %idxprom1<br>
%6 = bitcast %struct.S* %arrayidx2 to i8*<br>
%7 = bitcast %struct.S* %arrayidx to i8*<br>
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %6, i8* align 4 %7, i64 12, i1 false)<br>
br label %for.inc<br>
```<br>
<br>
It can be transformed into a single memcpy:<br>
<br>
```<br>
for.body.preheader: ; preds = %entry<br>
%b10 = bitcast %struct.S* %b to i8*<br>
%a9 = bitcast %struct.S* %a to i8*<br>
%0 = zext i32 %n to i64<br>
%1 = mul nuw nsw i64 %0, 12<br>
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %a9, i8* align 4 %b10, i64 %1, i1 false)<br>
br label %for.cond.cleanup<br>
```<br>
<br>
The problem is, if the copied elements are a class, this doesn't work. For a<br>
class with the same members:<br>
```<br>
%class.C = type <{ i32, i32, i8, [3 x i8] }><br>
```<br>
<br>
Clang does some optimization to generate a memcpy of nine bytes, omitting the<br>
tail padding:<br>
<br>
```<br>
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %6, i8* align 4 %7, i64 9, i1 false)<br>
```<br>
<br>
Then in LLVM, we find the memcpy is not touching every byte of the array, so<br>
we abort the transformation.<br>
<br>
If we could tell the untouched three bytes are padding, we should be able to<br>
still do the optimization, but LLVM doesn't seem to have this information. I<br>
tried using `DataLayout::getTypeStoreSize()`, and it returned 12 bytes. I also<br>
tried `StructLayout`, and it treats the tail padding as a regular class member.<br>
<br>
Is there an API in LLVM to tell if a class has tail padding? If not, would it<br>
be useful to add this feature?<br>
<br>
Thanks,<br>
Han<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>