<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 13, 2015 at 1:07 PM, Ansari, Zia <span dir="ltr"><<a href="mailto:zia.ansari@intel.com" target="_blank">zia.ansari@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-US">
<div><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regarding 24449, the optimization would be nice to do, as long as we’re careful we don’t create additional hazards with the larger memory instructions. Specifically,
 we don’t want to start splitting cache lines.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"></span><br></p></div></div></blockquote><div><br></div><div>Hi Zia -<br><br></div><div>Crossing a cache line is not a constraint that we take into account today when merging. Can you give us an idea about the penalty? Sorry if this is in the Opt Guide, and I've overlooked it. Possibly related: we do split unaligned 32-byte AVX memory accesses for SandyBridge (grep for Mem32Slow), but not any other chips.<br><br>I don't see a good mechanism for us to detect a cache line crossing when we're doing these memory access merges. We could assume that anything with alignment under the cache line size should not be merged, but that would rule out almost all merging. Eg, it's very unlikely that we'd ever see a 4-byte access specified with alignment 64.<br></div><div><br> </div></div></div></div>