<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/22/2017 09:18 PM, Xinliang David
Li via llvm-commits wrote:<br>
</div>
<blockquote
cite="mid:CALRgJCMMSmhsFQW8U9U8qVYF7UUCXaOjkABovCPPcy0vNxE_tg@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 Tue, Aug 22, 2017 at 7:10 PM,
Chandler Carruth via llvm-commits <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org"
target="_blank">llvm-commits@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote"><span class="">
<div dir="ltr">On Tue, Aug 22, 2017 at 7:03 PM
Xinliang David Li via cfe-commits <<a
moz-do-not-send="true"
href="mailto:cfe-commits@lists.llvm.org"
target="_blank">cfe-commits@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Aug 22, 2017
at 6:37 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>
I'm really not a fan of the degree of
complexity and subtlety that this
introduces into the frontend, all to allow
particular backend optimizations.<br>
<br>
I feel like this is Clang working around a
fundamental deficiency in LLVM and we
should instead find a way to fix this in
LLVM itself.<br>
<br>
As has been pointed out before, user code
can synthesize large integers that small
bit sequences are extracted from, and
Clang and LLVM should handle those just as
well as actual bitfields.<br>
<br>
Can we see how far we can push the LLVM
side before we add complexity to Clang
here? I understand that there remain
challenges to LLVM's stuff, but I don't
think those challenges make *all* of the
LLVM improvements off the table, I don't
think we've exhausted all ways of
improving the LLVM changes being proposed,
and I think we should still land all of
those and re-evaluate how important these
issues are when all of that is in place.<br>
</blockquote>
<div><br>
</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>The main challenge of doing this in
LLVM is that inter-procedural analysis
(and possibly cross module) is needed (for
store forwarding issues).</div>
<div><br>
</div>
<div>Wei, perhaps you can provide concrete
test case to illustrate the issue so that
reviewers have a good understanding.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>It doesn't seem like all options for addressing
that have been exhausted. And even then, I feel like
trying to fix this with non-obvious (to the
programmer) frontend heuristics isn't a good
solution. I actually *prefer* the source work around
of "don't use a bitfield if you *must* have narrow
width access across modules where the optimizer
cannot see enough to narrow them and you happen to
know that there is a legal narrow access that
works". Because that way the programmer has
*control* over this rather than being at the whim of
whichever side of the heuristic they end up on.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>The source workaround solution *does not* scale. Most
importantly, user may not even be aware of the problem
(and performance loss) unless compiling the code with
another compiler and notice the performance difference.</div>
</div>
</div>
</div>
</blockquote>
<br>
I agree with this, but it's not clear that this has to scale in that
sense. I don't like basing this on the bitfield widths because it
makes users pick between expressing semantic information and
expressing target tuning information using the same construct. What
if the optimal answer here is different on different platforms? I
don't want to encourage users to ifdef their aggregates to sometimes
be bitfields and sometimes not for tuning reasons. If need be,
please add an attribute. Any heuristic that you pick here is going
to help some cases and hurt others. If we're at the level of needing
IPA to look at store-to-load forwarding effects, then we've really
already lost. Either you need to actually do the IPA, or even in the
backend, any heuristic that you choose will help some things and
hurt others. Hopefully, we're not really there yet. I'm looking
forward to seeing more examples of the kinds of problems you're
trying to solve.<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:CALRgJCMMSmhsFQW8U9U8qVYF7UUCXaOjkABovCPPcy0vNxE_tg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>David</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>David</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div
class="m_-8403912814972070661m_5508161617453186913HOEnZb">
<div
class="m_-8403912814972070661m_5508161617453186913h5"><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>
</div>
</div>
</span>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-commits@lists.llvm.org"
target="_blank">cfe-commits@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</blockquote>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<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>