<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>+1 to what James said. My reaction to the original proposal is a
strong -1, and James did a good job of explaining why.</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 4/14/21 11:57 AM, James Y Knight via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA2zVHo9p5+A38Lz+4NrWMC193vE6qrdjVw914k9L8PzZZ7EDw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">This is not a principled change -- it avoids a
problem arising from <i>one</i> use of alignment information,
but there are other uses of alignment in LLVM, and those will
still cause problems, potentially less clearly. So, I think that
this will not be a useful option to provide to users, in this
form.
<div><br>
</div>
<div>What I suspect you <i>actually</i> want here is an option
to tell Clang not to infer load/store alignments based on
object types or alignment attributes -- instead treating
everything as being potentially aligned to 1 unless the
allocation is seen (e.g. global/local variables). Clang would
still need to use the usual alignment computation for variable
definitions and structure layout, but not memory operations.
If clang emits "load ... align 1" instructions in LLVM IR, the
right thing would then happen in the X86 backend
automatically.</div>
<div><br>
</div>
<div>My initial inclination is that this feature is also not
particularly worthwhile to implement, but I'm open to being
convinced that this is indeed valuable enough to be
worthwhile. It should actually work reliably, and is somewhat
in line with other such "not-quite-C" flags we provide (e.g.
-fno-delete-null-pointer-checks). Of course, even with such an
implementation, you can still have a problem with user code
depending on alignof() returning a reliable answer (e.g.,
llvm::PointerUnion). Not much can be done about that.</div>
<div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Apr 14, 2021 at 2:07
PM Liu, Chen3 via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">Hi all.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We want to make a patch to always
emit unaligned vector move instructions on AVX machine
with option control. We do this for the following
reason:</p>
<p class="MsoNormal"> </p>
<ol style="margin-top:0in" type="1" start="1">
<li style="margin-left:0in;text-align:justify">
With AVX the performance for aligned vector move and
unaligned vector move on X86 are the same if the
address is aligned. In this case we prefer to use
unaligned move because it can avoid some run time
exceptions;</li>
<li style="margin-left:0in;text-align:justify">
This fixes an inconsistency in optimization: suppose a
load operation was merged into another instruction
(e.g., load and add becomes `add [memop]'). If a
misaligned pointer is passed to the two-instruction
sequence, it will</li>
</ol>
<p style="text-align:justify">
raise an exception. If the same pointer is passed to the
memop instruction, it will work. Thus, the behavior of
misalignment depends upon what optimization levels and
passes are applied, and small source changes could cause</p>
<p style="text-align:justify">
issues to appear and disappear. It's better for the user
to consistently use unaligned load/store to improve the
debug experience;</p>
<ol style="margin-top:0in" type="1" start="3">
<li
style="margin-top:0in;margin-bottom:0in;text-align:justify;line-height:20.4pt;background:white"><span
style="color:black">Makes good use of HW that is
capable of handling misaligned data gracefully. It
is not necessarily a bug in users code but a
third-part library. For example it would allow using
a library built in old ages where stack alignment
was 4-byte only.</span></li>
<li style="margin-left:0in;text-align:justify">
Compatible with ICC so that users can easily use llvm;</li>
</ol>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Roman Lebedev is worried that this
patch will hide UB. In our opinions, UB doesn't have to
mean raise an exception. The example code(<a
href="https://godbolt.org/z/43bYPraoa" target="_blank"
moz-do-not-send="true">https://godbolt.org/z/43bYPraoa</a>)
does have UB behavior but it is still valid (and
reasonable) to interpret that UB as `go slower',</p>
<p class="MsoNormal">instead of `raise exception'.
Besides, as default we still emit aligned instructions
as before, but we provide an option for users with this
need.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We have two patches discussing this
issue, one of which has been abandoned:</p>
<p class="MsoNormal"><a
href="https://reviews.llvm.org/D88396" target="_blank"
moz-do-not-send="true">https://reviews.llvm.org/D88396</a>
(abandoned)</p>
<p class="MsoNormal"><a
href="https://reviews.llvm.org/D99565" target="_blank"
moz-do-not-send="true">https://reviews.llvm.org/D99565</a>
(in review)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks.</p>
<p class="MsoNormal">Chen Liu.</p>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>