<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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";}
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.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
.MsoPapDefault
{mso-style-type:export-only;
line-height:115%;}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We already perform optimizations only when the compiler can prove they won’t break the program.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The only difference between that and what you suggest is in the definition of “won’t break the program”. We define it as “won’t break the program with respect
to the semantics implied by the C/C++ spec”. <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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">You want to redefine it, by specifying a new abstract machine, which is more conservative than standard C/C++. The proper way to do that would, I believe, be
to work towards setting up a working group within the relevant committees, and come up with a uniformly accepted definition for this abstract machine, which could then be implemented (assuming there is, indeed, wide enough agreement in the implementer community
– something that does not look at all likely) by next-generation compilers.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Point is – I think you’re barking up the wrong tree.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This isn’t an llvm-dev issue, it’s a standards committee issue.<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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Michael<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>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Russell Wallace<br>
<b>Sent:</b> Wednesday, July 01, 2015 22:22<br>
<b>To:</b> Tim Northover<br>
<b>Cc:</b> llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] C as used/implemented in practice: analysis of responses<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="line-height:115%">I am arguing in favor of a point, and I understand you disagree with it, but I don't think I'm dismissing any use cases except a very small performance increment. Furthermore, the compiler would still be free to
perform such optimisations where it can prove they won't break the program. That's not all cases, to be sure, but at least we would then be back to the normal scenario where over the years as the compiler gets smarter, things get better, as opposed to monkey's
paw optimisations which cause a smarter compiler to make things worse.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="line-height:115%">On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="line-height:115%">On 1 July 2015 at 11:34, Russell Wallace <<a href="mailto:russell.wallace@gmail.com">russell.wallace@gmail.com</a>> wrote:<br>
> Why do you say spin?<br>
<br>
You're dismissing all use-cases other than this very narrow one I'd<br>
(with my own spin) characterise as "Do What I Mean, I Can't Be<br>
Bothered To Get My Code Right". Fair enough, you're arguing in favour<br>
of a point; but it's not one I agree with.<br>
<span style="color:#888888"><br>
<span class="hoenzb">Tim.</span></span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="line-height:115%"><o:p> </o:p></p>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>