<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Does the test case indicate the why it was added?</div><div><br></div><div>More of an implementation observation than a language interpretation, but if you add a "long l[6];" field, llvm-gcc continues to do field-by-field copies, but at l[7] it turns into machine-word copies, then at some point it turns into a rep/movsl (on Intel), and then at another threshold it turns into a memcpy(3) callout.</div><div><br></div><div>What part of LLVM's codegen for copying "struct x { char c; short s; long l[6] };" considers a movb + movw + 6 movl's to efficient in either time or space (I was using -Os)? What changes when the overall structure gets to 64 bytes such that it decides its more efficient to copy a word at a time?</div><div><br></div><div>I think the test case is bogus in terms of language correctness, but it might be indicative of a missed optimization for doing structure copies. Is that what GCC's test case is actually trying to validate? If so, it probably falls under a "gcc test case" and not a "C test case", if one can differentiate them.</div><div><br></div><div>Maybe it would be reasonable for llvm-gcc to NOT copy the padding at -O0 and do explicit field copies, but to copy the padding as a side effect of an inlined memcpy() implementation for copying sizeof(struct x) when optimization is used. Copying using the largest appropriate registers/instructions given the structure size and alignment seems like it would always be faster than field copies, even for small structures.</div><div><br></div><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Shantonu</div><div><br class="webkit-block-placeholder"></div><div>Sent from my MacBook</div></div></span></div></span> </div><br><div><html>On Mar 11, 2008, at 9:47 PM, Patrick Meredith wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> I thought pointer referencing like this was only valid for arrays. I could be wrong, but it might be that looping over the struct like that<div>is invalid, making it undefined behavior (and then the hole doesn't matter because there is no valid way to access it). That said, I've definitely</div><div>seen a lot of code that uses pointers to reference struct contents.</div><div><br><div><div>On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Looking through the gcc testsuite turned up an interesting edge case. Let's assume our target leaves a hole for alignment in struct x, as do x86 and powerpc. Do you think the following code can validly abort?</div><div><br class="webkit-block-placeholder"></div><div><div> struct x { char c; short s; };</div><div> int i; char *p;</div></div><div> memset(&X, 0, sizeof(struct x));</div><div> memset(&Y, 22, sizeof(struct x));</div><div> X = Y;</div><div> for (i=0, p=(char *)&X; i<sizeof(struct x); i++, p++)</div><div> if (*p != 22)</div><div> abort();</div><div><br class="webkit-block-placeholder"></div><div>The memset's and char-by-char comparison are clearly valid references; the questionable bit is the struct copy, which llvm-gcc currently does field-by-field, skipping the hole. C99 says</div><div><br class="webkit-block-placeholder"></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">In <i>simple assignment</i><span style="font: 12.0px Helvetica"> </span>(<span style="font: 12.0px Courier"><b>=</b></span>), the value of the right operand is converted to the type of the<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">assignment expression and replaces the value stored in the object designated by the left<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">operand.<span style="font: 12.0px Helvetica"> </span></div><div><br class="webkit-block-placeholder"></div><div>I would take "replaces the value" to mean "replaces the entire value", but it could be read otherwise, I suppose. </div><div><br class="webkit-block-placeholder"></div><div>The current code seems to me to assume holes in structs can't ever be validly accessed, which isn't right, as we see here. They are often nondeterministic (this is explicit for initialization in C99) but not always.</div><div><br></div> </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">LLVM Developers mailing list</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <span class="Apple-converted-space"> </span><a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div> </blockquote></div><br></div></div>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>