<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 08/09/2017 10:37 PM, Hal Finkel via
llvm-commits wrote:<br>
</div>
<blockquote cite="mid:913c78e9-91e9-6bba-6179-737688cd0185@anl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 08/09/2017 10:14 PM, Xinliang
David Li via llvm-commits wrote:<br>
</div>
<blockquote
cite="mid:CAAkRFZ+DG6+utT8t=PWP68tM3t8PUNSDQ+rViRrkp97BdEn-EA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 9, 2017 at 7:42 PM,
Chandler Carruth via Phabricator <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">chandlerc
added a comment.<br>
<br>
This has been discussed before and I still pretty
strongly disagree with it.<br>
<br>
This cripples the ability of TSan to find race
conditions between accesses to consecutive bitfields --
and these bugs have actually come up.<br>
<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Can you elaborate on this? Do you mean race
conditions due to widening?</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> We
also have had cases in the past where LLVM missed
significant bitfield combines and optimizations due to
loading them as separate integers. Those would become
problems again, and I think they would be even harder to
solve than narrowing the access is going to be because
we will have strictly less information to work with.<br>
<br>
</blockquote>
<div><br>
</div>
<div> Can you elaborate here too? If there were missed
optimization that later got fixed, there should be
regression tests for them, right? <br>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<br>
Also, on this, unfortunately, no. The problem is that the
optimization would be tested using a specific regression test. That
test will continue to pass even if you change the IR that frontend
generates so that the test no longer represents the
partially-optimized IR pattern that the frontend will help create.
This is why our tendency to rely only on pass-specific regression
tests, and not having end-to-end tests, is not necessarily optimal.<br>
<br>
-Hal<br>
<br>
<blockquote cite="mid:913c78e9-91e9-6bba-6179-737688cd0185@anl.gov"
type="cite">
<blockquote
cite="mid:CAAkRFZ+DG6+utT8t=PWP68tM3t8PUNSDQ+rViRrkp97BdEn-EA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> And what information is missing?</div>
</div>
</div>
</div>
</blockquote>
<br>
To make a general statement, if we load (a, i8) and (a+2, i16),
for example, and these came from some structure, we've lost the
information that the load (a+1, i8) would have been legal (i.e. is
known to be deferenceable). This is not specific to bit fields,
but the fact that we lose information on the dereferenceable byte
ranges around memory access turns into a problem when we later
can't legally widen. There may be a better way to keep this
information other than producing wide loads (which is an imperfect
mechanism, especially the way we do it by restricting to legal
integer types), but at the moment, we don't have anything better.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAAkRFZ+DG6+utT8t=PWP68tM3t8PUNSDQ+rViRrkp97BdEn-EA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>thanks,</div>
<div><br>
</div>
<div>David</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Ultimately, while I understand the appeal of this
approach, I don't think it is correct and I think we
should instead figure out how to optimize these memory
accesses well in LLVM. That approach will have the added
benefit of optimizing cases where the user has manually
used a large integer to simulate bitfields, and making
combining and canonicalization substantially easier.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
Repository:<br>
rL LLVM<br>
<br>
<a moz-do-not-send="true"
href="https://reviews.llvm.org/D36562"
rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D36562</a><br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>