<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/05/2014 11:08 AM, Arnaud A. de
Grandmaison wrote:<br>
</div>
<blockquote cite="mid:000a01cff92b$ddf0ced0$99d26c70$@arm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></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"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"
lang="EN-US"> Philip Reames
[<a class="moz-txt-link-freetext" href="mailto:listmail@philipreames.com">mailto:listmail@philipreames.com</a>] <br>
<b>Sent:</b> 05 November 2014 19:25<br>
<b>To:</b> Reid Kleckner<br>
<b>Cc:</b> Arnaud De Grandmaison; Nick Lewycky; Rafael
Ávila de Espíndola; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] lifetime.start/end
clarification<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On 11/05/2014
10:10 AM, Reid Kleckner wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On Wed,
Nov 5, 2014 at 10:01 AM, Philip Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank">listmail@philipreames.com</a>>
wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Would
one of you mind taking a step back and explaining
what you believe the "stack colouring problem" to
be? I'm familiar with the general meaning of the
term and even some of LLVM's implementation; I'm
just not sure what specific issue you're referring
to. Having the context would make it much easier
to assess your proposals. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">The
goal of stack coloring is to reduce stack usage by
storing user data with non-overlapping lifetimes in
the same stack memory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">C/C++
source programs usually have a naturally scoped
structure, where the lifetime of data is bounded by
curly braces. This information reduces the lifetime
that stack coloring sees, so it saves stack memory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">When
we go to LLVM IR, we lose all that information. We
currently try to recapture it with calls to
@lifetime.start / end intrinsic calls at the point
of declaration and when the variable falls out of
scope. Basically we're trying to figure out how to
put that scoping information back into the IR
without turning it back into a tree.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Furthermore,
if we had better information about this in the IR,
we could augment ASan to detect use-after-scope.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"
style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">Everything
you say here is general goodness. What part of this is
problematic today? My belief is that the lifetime markers
give you exactly the support you need. Where does this break
down? Is the analysis too hard? Is Clang getting the
semantics wrong? What's the actually blocking issue?<br>
<br>
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Here
is the actually blocking issue. Today, the lifetime markers
are only inserted if the alloca is big enough (32+ bytes). I
tried several times to add the lifetime markers for unnamed
temporaries; the patches have been reviewed each time by
people knowledgeable with this part of clang. But when we
remove the size limit for the lifetime marker insertion, we
get miscompiles when bootstrapping clang. This is why I was
asking for clarification of the specification, as this is a
part I found left room for interpretation.</span></p>
</div>
</blockquote>
Ah, okay. The context helps. Unfortunately, I think you're going
to have to do this the hard way. Find a miscompile, reduce it down
to an analysable test case, and then identify the bug. I don't
envy you the experience. :( You might try running a build with
restricted optimization (say, no inlining) to see if you can isolate
a small test case.<br>
<br>
My (completely unsupported) guess would be that you're going find
undefined behaviour in clang which is being exploited by the
optimizer. Would any of the sanitizers help with this? If not, you
could try the naive version: generate a clobbering store in place of
the lifetime intrinsic, see if you can make it crash. <br>
<br>
Philip<br>
<br>
</body>
</html>