<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 11:01 PM, Xinliang David
Li wrote:<br>
</div>
<blockquote
cite="mid:CAAkRFZ+ebwFDFsCUA0yKPRU8UMiVtnYhx+0LoDttnq8zkh6YNQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 9, 2017 at 8:44 PM, Hal
Finkel <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p><br>
</p>
<div class="m_-6078951405013076010moz-cite-prefix">On
08/09/2017 10:37 PM, Hal Finkel via llvm-commits
wrote:<br>
</div>
<blockquote type="cite">
<p><br>
</p>
<div class="m_-6078951405013076010moz-cite-prefix">On
08/09/2017 10:14 PM, Xinliang David Li via
llvm-commits wrote:<br>
</div>
<blockquote 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>
</span> 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.
</div>
</blockquote>
<div><br>
</div>
<div>If widening is expected in the result, the end state IR
can still be checked without the need for end-end testing.</div>
</div>
</div>
</div>
</blockquote>
<br>
I don't understand what you mean. Exactly what test do you think we
would have?<br>
<br>
<blockquote
cite="mid:CAAkRFZ+ebwFDFsCUA0yKPRU8UMiVtnYhx+0LoDttnq8zkh6YNQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> This is why our
tendency to rely only on pass-specific regression tests,
and not having end-to-end tests, is not necessarily
optimal.<span class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
</blockquote>
<div><br>
</div>
<div>End-end tests still exist, especially performance
regression tests -- missing optimizations will likely
result in performance regressions in real world
applications, or else it probably does not matter :)</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes. However, we have very few performance regression tests. There
are a lot of real-world applications, many of which have different
dynamic states in which different routines are important, many more
configurations than any of us can ever benchmark, profile, or
analyze. So we do what we can on that front, and then we rely on
consistency, generality, and robustness to hopefully cover all of
the rest of them. Professional judgment comes in when we weigh the
costs of that generality, robustness, and consistency vs. the costs
of development.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAAkRFZ+ebwFDFsCUA0yKPRU8UMiVtnYhx+0LoDttnq8zkh6YNQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>David</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font
color="#888888"> -Hal</font></span>
<div>
<div class="h5"><br>
<br>
<blockquote type="cite">
<blockquote 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 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="m_-6078951405013076010HOEnZb">
<div class="m_-6078951405013076010h5"><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/D3656<wbr>2</a><br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset
class="m_-6078951405013076010mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
llvm-commits mailing list
<a moz-do-not-send="true" class="m_-6078951405013076010moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>
<a moz-do-not-send="true" class="m_-6078951405013076010moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<pre class="m_-6078951405013076010moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
<fieldset class="m_-6078951405013076010mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
llvm-commits mailing list
<a moz-do-not-send="true" class="m_-6078951405013076010moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>
<a moz-do-not-send="true" class="m_-6078951405013076010moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<pre class="m_-6078951405013076010moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></div></div>
</blockquote></div>
</div></div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre></body></html>