<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hypothesizing about architectures with larger-than-cacheline vectors, there’s also the possibility of changing externally observable behavior by loading a catchline-sized donut hole.</div><div class=""><br class=""></div><div class="">I believe that a very conservative set of criteria that nonetheless license this almost all the time is something like</div><div class=""><br class=""></div><div class="">1. both ends of vector are used</div><div class="">2. vector is smaller than a cacheline</div><div class="">3. not FP, or arch doesn’t raise flags on FP loads (most)</div><div class="">4. not volatile or atomic</div><div class=""><br class=""></div><div class="">– Steve</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 2:28 PM, Sanjay Patel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">We are careful not to try this optimization where it would extend the range of loaded memory; this is purely for what I call a "load doughnut". :)<br class="">Reading past either specified edge would be very bad because it could cause a memory fault / exception where there was none in the original program. That's definitely not legal.<br class=""><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 16, 2016 at 12:20 PM, Craig, Ben <span dir="ltr" class=""><<a href="mailto:ben.craig@codeaurora.org" target="_blank" class="">ben.craig@codeaurora.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="">
I'm having a hard time finding any problems here, at least as long
as the value is in the middle. I wouldn't expect the contents of
x[2] to affect the timing or power usage of anything. I guess there
would be a minor "bad" side effect in that a memory read watchpoint
would trigger with the 128 bit load that wouldn't be there with the
32-bit loads. I think it is semantically very similar to this
situation as well...<br class="">
<blockquote class="">v4i32 first_call(int *x) { //use all of the array<br class="">
int f0 = x[0];<br class="">
int f1 = x[1];<br class="">
int f2 = x[2];<br class="">
int f3 = x[3];<br class="">
return (v4i32) { f0, f1, f2, f3 };<br class="">
}<br class="">
v4i32 second_call(int *x) { //use some of the array<br class="">
int s0 = x[0];<br class="">
int s1 = x[1];<br class="">
int s2 = 0;<br class="">
int s3 = x[3];<br class="">
return (v4i32) { s0, s1, s2, s3 };<br class="">
}<br class="">
first_call(x);<br class="">
second_call(x);<br class="">
</blockquote>
The implementation isn't going to zero out the stack in between
those calls, so for a short period of time, the memory location of
s2 will contain x[2].<br class="">
<br class="">
I'm less sure if the gaps are on the edges. I'm worried that you
might ending up crossing some important address boundary if you look
at something earlier or later than what the user requested.<div class=""><div class="h5"><br class="">
<br class="">
<div class="">On 3/16/2016 11:38 AM, Sanjay Patel
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">Hi Ben -<br class="">
</div>
<br class="">
Thanks for your response. For the sake of argument, let's
narrow the scope of the problem to eliminate some of the
variables you have rightfully cited. <br class="">
<br class="">
Let's assume we're not dealing with volatiles, atomics, or FP
operands. We'll even guarantee that the extra loaded value is
never used. This is, in fact, the scenario that <a href="http://reviews.llvm.org/rL263446" target="_blank" class=""></a><a href="http://reviews.llvm.org/rL263446" target="_blank" class="">http://reviews.llvm.org/rL263446</a>
is concerned with.<br class="">
<br class="">
</div>
Related C example:<br class="">
<br class="">
typedef int v4i32 __attribute__((__vector_size__(16)));<br class="">
<br class="">
// Load some almost-consecutive ints as a vector.<br class="">
v4i32 foo(int *x) {<br class="">
int x0 = x[0];<br class="">
int x1 = x[1];<br class="">
// int x2 = x[2]; // U can't touch this? <br class="">
int x3 = x[3];<br class="">
return (v4i32) { x0, x1, 0, x3 };<br class="">
}<br class="">
<br class="">
<div class="">
<div class="">For x86, we notice that we have nearly a v4i32 vector's
worth of loads, so we just turn that into a vector load and
mask out the element that's getting set to zero:<br class="">
movups (%rdi), %xmm0 ; load 128-bits
instead of three 32-bit elements<br class="">
andps LCPI0_0(%rip), %xmm0 ; put zero bits into the
3rd element of the vector<br class="">
<br class="">
</div>
<div class="">Should that optimization be disabled by a hypothetical
-fextra-secure flag?<br class="">
</div>
<div class=""><br class="">
<br class="">
</div>
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Mar 16, 2016 at 7:59 AM, Craig,
Ben <span dir="ltr" class=""><<a href="mailto:ben.craig@codeaurora.org" target="_blank" class="">ben.craig@codeaurora.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class=""> Regarding accessing
extra data, there are at least some limits as to what can
be accessed. You can't generate extra loads or stores to
volatiles. You can't generate extra stores to atomics,
even if the extra stores appear to be the same value as
the old value.<br class="">
<br class="">
As for determining where the perf vs. security line should
be drawn, I would argue that most compilers have gone too
far on the perf side while optimizing undefined behavior.
Dead store elimination leaving passwords in memory,
integer overflow checks getting optimized out, and NULL
checks optimized away. Linus Torvalds was complaining
about those just recently on this list, and while I don't
share his tone, I agree with him regarding the harm these
optimizations can cause.<br class="">
<br class="">
If I'm understanding correctly, for your specific cases,
you are wondering if it is fine to load and operate on a
floating point value that the user did not specifically
request you to operate on. This could cause (at least)
two different problems. First, it could cause a floating
point exception. I think the danger of the floating point
exception should rule out loading values the user didn't
request. Second, loading values the user didn't specify
could enable a timing attack. The timing attack is scary,
but I don't think it is something we can really fix in the
general case. As long as individual assembly instructions
have impractical-to-predict execution times, we will be at
the mercy of the current hardware state. There are timing
attacks that can determine TLS keys in a different VM
instance based off of how quickly loads in the current
process execute. If our worst timing attack problems are
floating point denormalization issues, then I think we are
in a pretty good state.
<div class="">
<div class=""><br class="">
<br class="">
<div class="">On 3/15/2016 10:46 AM, Sanjay Patel via llvm-dev
wrote:<br class="">
</div>
</div>
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">[cc'ing cfe-dev because this may require
some interpretation of language law]<br class="">
<br class="">
My understanding is that the compiler has
the freedom to access extra data in C/C++
(not sure about other languages); AFAIK, the
LLVM LangRef is silent about this. In C/C++,
this is based on the "as-if rule":<br class="">
<a href="http://en.cppreference.com/w/cpp/language/as_if" target="_blank" class="">http://en.cppreference.com/w/cpp/language/as_if</a><br class="">
</div>
</div>
<br class="">
</div>
So the question is: where should the optimizer
draw the line with respect to perf vs. security if
it involves operating on unknown data? Are there
guidelines that we can use to decide this?<br class="">
<br class="">
<div class="">
<div class="">The masked load transform referenced below
is not unique in accessing / operating on
unknown data. In addition to the related
scalar loads -> vector load transform that
I've mentioned earlier in this thread, see for
example:<br class="">
<a href="https://llvm.org/bugs/show_bug.cgi?id=20358" target="_blank" class="">https://llvm.org/bugs/show_bug.cgi?id=20358</a><br class="">
<div class="">(and the security paper and patch review
linked there)<br class="">
</div>
<br class="">
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Mar 14, 2016 at
10:26 PM, Shahid, Asghar-ahmad <span dir="ltr" class=""><<a href="mailto:Asghar-ahmad.Shahid@amd.com" target="_blank" class="">Asghar-ahmad.Shahid@amd.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US" class="">
<div class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Hi
Sanjay,</span></p>
<span class=""><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">>The
real question I have is whether it
is legal to read the extra memory,
regardless of whether this is a
masked load or </span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">>something
else.</span></p>
</span><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">No,
It is not legal AFAIK because by
doing that we are exposing the
content of the memory which
programmer</span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">does
not intend to. This may be
vulnerable for exploitation.</span></p><div style="margin-bottom: 12pt;" class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Regards,</span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Shahid</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div>
<div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue;padding:0in 0in 0in 4pt" class="">
<div class="">
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) -moz-use-text-color -moz-use-text-color;padding:3pt 0in 0in" class=""><p class="MsoNormal"><b class=""><span style="font-size:10pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10pt;font-family:"Tahoma","sans-serif"" class="">
llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" class=""></a><a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" class="">llvm-dev-bounces@lists.llvm.org</a>]
<b class="">On Behalf Of </b>Sanjay
Patel via llvm-dev<br class="">
<b class="">Sent:</b> Monday, March 14,
2016 10:37 PM<br class="">
<b class="">To:</b> Nema, Ashutosh<br class="">
<b class="">Cc:</b> llvm-dev<br class="">
<b class="">Subject:</b> Re: [llvm-dev]
masked-load endpoints
optimization</span></p>
</div>
</div>
<div class="">
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<div class=""><p class="MsoNormal">I checked
in a patch to do this
transform for x86-only for
now:<br class="">
<a href="http://reviews.llvm.org/D18094" target="_blank" class="">http://reviews.llvm.org/D18094</a>
/ <a href="http://reviews.llvm.org/rL263446" target="_blank" class="">http://reviews.llvm.org/rL263446</a></p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<div class=""><p class="MsoNormal">On Fri,
Mar 11, 2016 at 9:57 AM,
Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank" class=""></a><a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>>
wrote:</p>
<div class="">
<div class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-bottom:12pt">Thanks,
Ashutosh.</p>
</div><p class="MsoNormal" style="margin-bottom:12pt">Yes,
either TTI or TLI
could be used to limit
the transform if we do
it in CGP rather than
the DAG.</p>
</div><p class="MsoNormal" style="margin-bottom:12pt">The
real question I have is
whether it is legal to
read the extra memory,
regardless of whether
this is a masked load or
something else.</p>
</div><p class="MsoNormal">Note
that the x86 backend
already does this, so
either my proposal is ok
for x86, or we're already
doing an illegal
optimization:</p>
<div class=""><p class="MsoNormal" style="margin-bottom:12pt"><br class="">
define <4 x i32>
@load_bonus_bytes(i32*
%addr1, <4 x i32>
%v) {<br class="">
%ld1 = load i32, i32*
%addr1<br class="">
%addr2 = getelementptr
i32, i32* %addr1, i64 3<br class="">
%ld2 = load i32, i32*
%addr2<br class="">
%vec1 = insertelement
<4 x i32> undef,
i32 %ld1, i32 0<br class="">
%vec2 = insertelement
<4 x i32> %vec1,
i32 %ld2, i32 3<br class="">
ret <4 x i32>
%vec2<br class="">
}<br class="">
<br class="">
$ ./llc -o -
loadcombine.ll <br class="">
...<br class="">
movups (%rdi),
%xmm0<br class="">
retq<br class="">
<br class="">
<br class="">
</p>
</div>
</div>
<div class="">
<div class="">
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<div class=""><p class="MsoNormal">On
Thu, Mar 10, 2016 at
10:22 PM, Nema,
Ashutosh <<a href="mailto:Ashutosh.Nema@amd.com" target="_blank" class=""></a><a href="mailto:Ashutosh.Nema@amd.com" target="_blank" class="">Ashutosh.Nema@amd.com</a>>
wrote:</p>
<div class="">
<div class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">This
looks
interesting,
the main
motivation
appears to be
replacing
masked vector
load with a
general vector
load followed
by a select.</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Observed
masked vector
loads are in
general
expensive in
comparison
with a vector
load.</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">But
if first &
last element
of a masked
vector load
are guaranteed
to be accessed
then it can be
transformed to
a vector load.</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">In
opt this can
be driven by
TTI, where the
benefit of
this
transformation
should be
checked.</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Regards,</span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class="">Ashutosh</span></p><div class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><b class=""><span style="font-size:11pt;font-family:"Calibri","sans-serif"" class="">From:</span></b><span style="font-size:11pt;font-family:"Calibri","sans-serif"" class="">
llvm-dev
[mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" class=""></a><a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" class="">llvm-dev-bounces@lists.llvm.org</a>]
<b class="">On Behalf
Of </b>Sanjay
Patel via
llvm-dev<br class="">
<b class="">Sent:</b>
Friday, March
11, 2016 3:37
AM<br class="">
<b class="">To:</b>
llvm-dev<br class="">
<b class="">Subject:</b>
[llvm-dev]
masked-load
endpoints
optimization</span></p>
<div class="">
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<div class="">
<div class="">
<div class=""><p class="MsoNormal" style="margin-bottom:12pt">If we're loading the first and last elements
of a vector
using a masked
load [1], can
we replace the
masked load
with a full
vector load?<br class="">
<br class="">
"The result of
this operation
is equivalent
to a regular
vector load
instruction
followed by a
‘select’
between the
loaded and the
passthru
values,
predicated on
the same mask.
However, using
this intrinsic
prevents
exceptions on
memory access
to masked-off
lanes."<br class="">
<br class="">
I think the
fact that
we're loading
the endpoints
of the vector
guarantees
that a full
vector load
can't have any
different
faulting/exception
behavior on
x86 and most
(?) other
targets. We
would,
however, be
reading memory
that the
program has
not explicitly
requested.</p>
</div><p class="MsoNormal">IR
example:<br class="">
<br class="">
define <4 x
i32>
@maskedload_endpoints(<4
x i32>*
%addr, <4 x
i32> %v) {</p>
</div><p class="MsoNormal">
; load the
first and last
elements
pointed to by
%addr and
shuffle those
into %v</p>
<div class=""><p class="MsoNormal" style="margin-bottom:12pt"> %res = call <4 x i32>
@llvm.masked.load.v4i32(<4
x i32>*
%addr, i32 4,
<4 x i1>
<i1 1, i1
0, i1 0, i1
1>, <4 x
i32> %v)<br class="">
ret <4 x
i32> %res<br class="">
}</p>
</div>
<div class=""><p class="MsoNormal">would
become
something
like:</p>
</div>
<div class=""><p class="MsoNormal"><br class="">
define <4 x
i32>
@maskedload_endpoints(<4
x i32>*
%addr, <4 x
i32> %v) {</p>
</div>
<div class=""><p class="MsoNormal">
%vecload =
load <4 x
i32>, <4
x i32>*
%addr, align 4</p>
</div>
<div class=""><p class="MsoNormal">
%sel = select
<4 x i1>
<i1 1, i1
0, i1 0, i1
1>, <4 x
i32>
%vecload,
<4 x
i32> %v</p>
</div>
<div class=""><p class="MsoNormal" style="margin-bottom:12pt"> ret <4 x i32> %sel<br class="">
}</p>
</div>
<div class=""><p class="MsoNormal">If
this isn't
valid as an IR
optimization,
would it be
acceptable as
a DAG combine
with target
hook to opt
in?</p>
</div>
<div class="">
<div class="">
<div class=""><p class="MsoNormal"><br class="">
[1] <a href="http://llvm.org/docs/LangRef.html#llvm-masked-load-intrinsics" target="_blank" class="">
</a><a href="http://llvm.org/docs/LangRef.html#llvm-masked-load-intrinsics" target="_blank" class=""></a><a href="http://llvm.org/docs/LangRef.html#llvm-masked-load-intrinsics" target="_blank" class="">http://llvm.org/docs/LangRef.html#llvm-masked-load-intrinsics</a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div><div class=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
</div>
</div><div class=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
<fieldset class=""></fieldset>
<br class="">
</div>
</div>
<pre class="">_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><span class=""><font color="#888888" class="">
</font></span></pre>
<span class=""><font color="#888888" class=""> </font></span></blockquote>
<span class=""><font color="#888888" class=""> <br class="">
<pre cols="72" class="">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</font></span></div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
<pre cols="72" class="">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</div></div></div>
</blockquote></div><br class=""></div></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>