<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>IMO, no. We should encourage sanitizers instead.</p>
<p>From experience, any code base where porting trips across this
probably also has a bunch of other undefined behavior which is
causing less obvious miscompiles, and also need found and fixed.
That's why we have sanitizers. <br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 4/15/21 7:07 AM, Luo, Yuanke via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN6PR11MB31355BDB6140B1B7F334DCF59A4D9@SN6PR11MB3135.namprd11.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Yes, replacing aligned move instruction
with unaligned move instruction doesn’t solve all the issue
that happens in optimization pipeline, but it doesn’t make
things worse. One advantage for unaligned move is that it
makes the behavior the same no matter the mov instruction is
folded or not. Do you think it is worth to support this
feature if compiler can help users avoid changing their
complex legacy code?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal">Yuanke<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> James Y Knight
<a class="moz-txt-link-rfc2396E" href="mailto:jyknight@google.com"><jyknight@google.com></a> <br>
<b>Sent:</b> Thursday, April 15, 2021 9:09 PM<br>
<b>To:</b> Liu, Chen3 <a class="moz-txt-link-rfc2396E" href="mailto:chen3.liu@intel.com"><chen3.liu@intel.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; Luo, Yuanke
<a class="moz-txt-link-rfc2396E" href="mailto:yuanke.luo@intel.com"><yuanke.luo@intel.com></a>; Maslov, Sergey V
<a class="moz-txt-link-rfc2396E" href="mailto:sergey.v.maslov@intel.com"><sergey.v.maslov@intel.com></a><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] [X86] Emit unaligned
vector moves on avx machine with option control.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 15, 2021 at 4:43 AM Liu,
Chen3 <<a href="mailto:chen3.liu@intel.com"
moz-do-not-send="true">chen3.liu@intel.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi,
James Y Knight.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm
not sure if you misunderstood this patch. This patch
won’t change any alignment information in IR and MI,
which means ‘load…align 32’ will always keep the
alignment information but select ‘vmovups’ instead
of ‘vmovaps’ during ISEL. It can be simply
considered that the only thing this patch does is to
replace the aligned-move mnemonic with the
unaligned-move mnemonic (in fact, we shouldn’t call
it replace but emit unaligned). I think there is no
impact on optimization or code layout. <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes -- I understood that, and that is
exactly why this patch is not OK. Giving LLVM incorrect
information about the alignment of objects causes
problems other than just the emission of movaps
instructions -- that alignment information is correct
gets relied upon throughout the optimization pipeline.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, a command-line option to "fix"
only that one instruction is not something which we can
reasonably provide, because it will not reliably fix
users' problems. A program which is being "mis"-compiled
due to the use of misaligned objects might still be
miscompiled by LLVM when using your proposed patch.
("mis" in quotes, since the compiler is correctly
compiling the code according to the standard, even if
not according to the user's expectations).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The second paragraph of my original
email describes an alternative patch that you could
write, which
<i>would</i> reliably fix such miscompilation --
effectively creating a variant of C where creating and
accessing misaligned objects has fully defined behavior.
(And, just to reiterate, my initial feeling is that
creating such an option is not a worthwhile endeavor,
but I could be persuaded otherwise.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">After
discussion, we think this option more like changing
the behavior when process with unaligned memory:
raising exception or accepting performance
degradation. Maybe the option is more like
“no-exception-on-unalginedmem”. We do have some
users want this feature. They can accept “run slow”
but do not want exception.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chen
Liu.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b>
Philip Reames <<a
href="mailto:listmail@philipreames.com"
target="_blank" moz-do-not-send="true">listmail@philipreames.com</a>>
<br>
<b>Sent:</b> Thursday, April 15, 2021 6:44 AM<br>
<b>To:</b> James Y Knight <<a
href="mailto:jyknight@google.com"
target="_blank" moz-do-not-send="true">jyknight@google.com</a>>;
Liu, Chen3 <<a
href="mailto:chen3.liu@intel.com"
target="_blank" moz-do-not-send="true">chen3.liu@intel.com</a>><br>
<b>Cc:</b> <a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>;
Luo, Yuanke <<a
href="mailto:yuanke.luo@intel.com"
target="_blank" moz-do-not-send="true">yuanke.luo@intel.com</a>>;
Maslov, Sergey V <<a
href="mailto:sergey.v.maslov@intel.com"
target="_blank" moz-do-not-send="true">sergey.v.maslov@intel.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] [X86] Emit
unaligned vector moves on avx machine with
option control.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<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.<o:p></o:p></p>
<p>Philip<o:p></o:p></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
4/14/21 11:57 AM, James Y Knight via llvm-dev
wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.
<o:p></o:p></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
all.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<ol type="1" start="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph;mso-list:l0
level1 lfo1">
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;<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph;mso-list:l0
level1 lfo1">
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<o:p></o:p></li>
</ol>
<p
style="text-align:justify;text-justify:inter-ideograph">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<o:p></o:p></p>
<p
style="text-align:justify;text-justify:inter-ideograph">issues
to appear and disappear. It's better for
the user to consistently use unaligned
load/store to improve the debug
experience;<o:p></o:p></p>
<ol type="1" start="3">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph;line-height:20.4pt;mso-list:l1
level1 lfo2;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><o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph;mso-list:l1
level1 lfo2">
Compatible with ICC so that users can
easily use llvm;<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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',<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">instead
of `raise exception'. Besides, as default
we still emit aligned instructions as
before, but we provide an option for
users with this need.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We
have two patches discussing this issue,
one of which has been abandoned:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a
href="https://reviews.llvm.org/D88396"
target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D88396</a>
(abandoned)<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a
href="https://reviews.llvm.org/D99565"
target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D99565</a>
(in review)<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chen
Liu.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<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"
target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</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>