<div dir="ltr"><div dir="ltr">Hmm, we have memory operations to the same location are not getting the same addressing metadata associated with them, similar to <a href="http://bugs.llvm.org/pr38241">bugs.llvm.org/pr38241</a>. Presumably there's a pass that's dropping that information on the floor. </div><div dir="ltr"><br></div><div>-NIrav</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 3:14 PM, Andres Freund <span dir="ltr"><<a href="mailto:andres@anarazel.de" target="_blank">andres@anarazel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 2018-09-11 15:06:10 -0400, Nirav Davé wrote:<br>
> Hmm. This looks like the backend conservatively giving up early on<br>
> merging.<br>
<br>
> It looks like you're running clang 5.02. There have been some improvements<br>
> to the backend's memory aliasing and store merging that have landed since.<br>
> Can you check if this is fixed in a newer version?<br>
<br>
</span>It's trunk at r341868.  The clang version numbers come in from postgres'<br>
JIT infrastructure inlining SQL operators/functions, which are just<br>
taken from postgres' C code.  I probably shouldn't have mixed versions<br>
in this installation, but it shouldn't affect the result, as that's only<br>
for the available_externally functions.  The rest of the IR is generated<br>
by directly emitting IR via IRBuilder.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Andres<br>
</font></span></blockquote></div><br></div>