<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Sorry, I was using a modified compiler,
which by coincidence made the bug much easier to reproduce.<br>
<br>
In some rare cases, the compiler will use x30 as a general-purpose
register; in that case, outlining breaks because the "ret"
branches to the wrong address. Testcase (reproduce with "clang
-O3 --target=aarch64-pc-linux-gnu -mllvm
-enable-machine-outliner"):<br>
<br>
extern long g1;<br>
extern long g2;<br>
void foo() {<br>
register long *x asm("x27") = &g1;<br>
register long *y asm("x29") = &g1;<br>
register long *z asm("x30") = &g2;<br>
asm(""::"r"(x),"r"(y),"r"(z));<br>
}<br>
void foo2() {<br>
register long *x asm("x27") = &g1;<br>
register long *y asm("x29") = &g1;<br>
register long *z asm("x30") = &g2;<br>
asm(""::"r"(x),"r"(y),"r"(z));<br>
}<br>
void foo3() {<br>
register long *x asm("x27") = &g1;<br>
register long *y asm("x29") = &g1;<br>
register long *z asm("x30") = &g2;<br>
asm(""::"r"(x),"r"(y),"r"(z));<br>
}<br>
<br>
-Eli<br>
<br>
On 4/23/2018 2:37 PM, Jessica Paquette wrote:<br>
</div>
<blockquote type="cite"
cite="mid:12EB8EB6-03F1-4F8D-82DD-0E6C5A13FF33@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
I just ran SPEC at -O3 with the outliner enabled for AArch64 and
didn’t get any failures on my end. Which flags did you use? I’m
curious about what’s going on here...
<div class=""><br class="">
<div class="">I used -O3 -mllvm -enable-machine-outliner -arch
arm64.</div>
<div class=""><br class="">
</div>
<div class="">- Jessica</div>
<div class="">
<div class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 23, 2018, at 1:41 PM, Jessica
Paquette <<a href="mailto:jpaquette@apple.com"
class="" moz-do-not-send="true">jpaquette@apple.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">Hi Eli,
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">I
just tried some tests, and I'm seeing a
bunch of failures on SPEC at -O3; looks like
mostly crashes at runtime. I can try to
reduce a testcase if you need it.</div>
</blockquote>
<div class="">If you could do that, that would
be great. Our testing has been primarily for
-Oz and -O2, so I haven’t looked at -O3 at
all.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF"
class="">I don't think this is really the
right approach. With LTO, you can have a
mix of functions, some of which are
minsize, and some of which are not. Or
with profile info, we might want to
outline only cold code (I guess this isn't
implemented yet, but potentially future
work). Tying whether we run the outliner
to a command-line flag restricts the
possible uses; either the entire module
gets outlining, or none of it does.</div>
</blockquote>
</div>
<div class="">I’m worried that walking the
entire list of functions in the module when
nothing has the minsize attribute would incur
unnecessary compile-time overhead. If that’s a
reasonable thing to do though, I’m fine with
that approach. It’d be a less invasive change,
and would give us the desired LTO behaviour
for free.</div>
<div class=""><br class="">
</div>
<div class="">- Jessica</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 23, 2018, at 1:24 PM,
Friedman, Eli <<a
href="mailto:efriedma@codeaurora.org"
class="" moz-do-not-send="true">efriedma@codeaurora.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<div text="#000000" bgcolor="#FFFFFF"
class="">
<div class="moz-cite-prefix">On
4/20/2018 7:06 PM, Jessica Paquette
via llvm-dev wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:E34BA217-F1D2-4319-AC37-3B1A51625D8F@apple.com"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<span style="font-family:
HelveticaNeue;" class="">We
perform regular testing to ensure
the outliner produces correct
AArch64 code at -Oz. Tests include
the LLVM test suite and standard
external test suites such as SPEC.
All tests compile and
execute. We've also been making
sure that the outliner produces
debuggable code. Users are still
guaranteed to have sane backtraces
in the presence of outlined
functions.</span><br class=""
style="font-family:
HelveticaNeue;">
<br class="" style="font-family:
HelveticaNeue;">
<span style="font-family:
HelveticaNeue;" class="">Added
exposure to various programs would
help the outlining algorithm
mature further. This, in turn,
will help the overall outlining
project. For example, there have
been a few discussions on
implementing an IR-level outlining
pass [3, 4]. Ultimately, the goal
is to create a shared outlining
interface. This interface would
allow the outliner to exist at any
level of representation [4]. The
general outlining algorithm will
be part of the shared interface.
Thus, in the spirit of incremental
improvement, it makes sense to
begin "stress-testing" it sooner
than later.</span><br class=""
style="font-family:
HelveticaNeue;">
</blockquote>
<br class="">
I just tried some tests, and I'm
seeing a bunch of failures on SPEC at
-O3; looks like mostly crashes at
runtime. I can try to reduce a
testcase if you need it.<br class="">
<br class="">
<blockquote type="cite"
cite="mid:E34BA217-F1D2-4319-AC37-3B1A51625D8F@apple.com"
class=""><br class=""
style="font-family:
HelveticaNeue;">
<font class="" face="HelveticaNeue">There
are a few patches necessary to
facilitate this. They are
available in the patches section
of this email. I’ll summarize what
they do here for the sake of
discussion though.</font><br
class="" style="font-family:
HelveticaNeue;">
<br class="" style="font-family:
HelveticaNeue;">
<span style="font-family:
HelveticaNeue;" class="">The first
patch is one that teaches the
backend about size optimization
levels. This is comparable to
what's done in the inliner. Today,
the only way to tell if something
is optimizing for size is by
looking at function attributes.
This is fine for function passes,
but insufficient for module passes
like the MachineOutliner. The
function attribute approach forces
the outliner to iterate over every
function in the module before
deciding to take action. If -Oz
isn't passed in, then the outliner
will not find any functions worth
outlining from. This would incur
unnecessary compile-time overhead.
Thus, we decided the best course
of action is to teach the backend
about size options.</span></blockquote>
<br class="">
I don't think this is really the right
approach. With LTO, you can have a
mix of functions, some of which are
minsize, and some of which are not.
Or with profile info, we might want to
outline only cold code (I guess this
isn't implemented yet, but potentially
future work). Tying whether we run
the outliner to a command-line flag
restricts the possible uses; either
the entire module gets outlining, or
none of it does.<br class="">
<br class="">
In general, we've been moving away
from global settings so we can
optimize more effectively in this sort
of scenario.<br class="">
<br class="">
-Eli<br class="">
<pre class="moz-signature" cols="72">--
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>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>