<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:03 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAAwGriF79f68p8CmxQSDCwx2QiB-rJa3PpD1v5Bxmot4+8T0zg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Hal already answered much of this, just continuing
this part of the discussion...
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Aug 9, 2017 at 8:56 PM Xinliang David
Li via llvm-commits <<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org">llvm-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 Wed, Aug 9, 2017 at 8:37
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>
<p><br>
</p>
<div
class="m_-2021915036012865282m_-1753555538924036895moz-cite-prefix">On
08/09/2017 10:14 PM, Xinliang David Li via
llvm-commits wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> Can you elaborate here too? If
there were missed optimization that
later got fixed, there should be
regression tests for them, right?
And what information is missing?</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> 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),</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I don't think we have such a restriction? Maybe I'm
missing something. When I originally added this logic, it
definitely was not restricted to legal integer types.</div>
</div>
</div>
</div>
</blockquote>
<br>
I believe you're right for bitfields. For general structures,
however, we certainly load individual fields instead of loading the
whole structure with some wide integer in order to preserve
dereferenceability information.<br>
<br>
<blockquote
cite="mid:CAAwGriF79f68p8CmxQSDCwx2QiB-rJa3PpD1v5Bxmot4+8T0zg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><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">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> but at the
moment, we don't have anything better.<br>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Ok, as you mentioned, widening looks like a
workaround to paper over the weakness in IR to
annotate the information. More importantly, my
question is whether this is a just theoretical
concern.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I really disagree with this being a workaround.</div>
<div><br>
</div>
<div>I think it is very fundamentally the correct model --
the semantics are that this is a single, wide memory
operation that a narrow data type is extracted from.</div>
</div>
</div>
</div>
</blockquote>
<br>
That is one option. We do need to preserve this information (maybe
we can do this with TBAA, or similar, or maybe using some other
mechanism entirely). However, we do try harder to do this with
bitfields than with other aggregates. If I have struct { int a, b,
c, d; } S; and I load S.d, we don't do this by loading a 128-bit
integer and then extracting some part of it. Should we? Probably
not. I suspect having better support for aggregate memory access
would be a better solution. Or, as noted, using metadata or some
other secondary mechanism.<br>
<br>
Maybe more aggressively preserving this information for bit fields
is the right answer, empirically. I can believe that's true. The
more-general problem still exists, however.<br>
<br>
<blockquote
cite="mid:CAAwGriF79f68p8CmxQSDCwx2QiB-rJa3PpD1v5Bxmot4+8T0zg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>I think the thing that is seriously weak is the ability
to aggressively narrow these operations, and while I agree
that this is important it doesn't actually seem to be
common. We have a relatively small number of (admitedly
important) cases, but even our existing narrowing seems to
be very effective for the vast majority of cases.</div>
<div><br>
</div>
<div>I would be very hesitant to give up the information
preserved by this lowering and representation when we
already have very successfully optimized the majority of
it effectively during code generation, and have only just
started trying a much more aggressive approach. I suspect
that the aggressive approach can be made to work, even
though it may be quite challenging.</div>
</div>
</div>
</div>
</blockquote>
<br>
The thing that appeals to me about the IR-transformation approach is
the ability to handle "hand coded" bit fields as effectively as
language-level bit fields. I've certainly seen my share of these,
and they're definitely important. Moreover, this is true regardless
of what we think about the underlying optimal model for preserving
aggregate derefereceability in general.<br>
<br>
-Hal<br>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>