<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 4:52 AM, Peter Sewell <span dir="ltr"><<a href="mailto:Peter.Sewell@cl.cam.ac.uk" target="_blank">Peter.Sewell@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2 July 2015 at 11:17, Kuperstein, Michael M<br>
<span class=""><<a href="mailto:michael.m.kuperstein@intel.com">michael.m.kuperstein@intel.com</a>> wrote:<br>
> We already perform optimizations only when the compiler can prove they won’t<br>
> break the program.<br>
><br>
> The only difference between that and what you suggest is in the definition<br>
> of “won’t break the program”. We define it as “won’t break the program with<br>
> respect to the semantics implied by the C/C++ spec”.<br>
><br>
><br>
><br>
> You want to redefine it, by specifying a new abstract machine, which is more<br>
> conservative than standard C/C++. The proper way to do that would, I<br>
> believe, be to work towards setting up a working group within the relevant<br>
> committees, and come up with a uniformly accepted definition for this<br>
> abstract machine, which could then be implemented (assuming there is,<br>
> indeed, wide enough agreement in the implementer community – something that<br>
> does not look at all likely) by next-generation compilers.<br>
><br>
><br>
><br>
> Point is – I think you’re barking up the wrong tree.<br>
><br>
> This isn’t an llvm-dev issue, it’s a standards committee issue.<br>
<br>
</span>This thread has diverged a bit since I was last here, and I'm not the<br>
one you were responding to above.  But as far as I'm concerned, the<br>
question for the LLVM community (and similarly the GCC community and<br>
other compiler developers) is, for each of the ways in which systems<br>
code and OS developers clearly are relying on behaviour that you don't<br>
think you currently support, what is the least-runtime-cost and<br>
least-effort way of doing so (and what is that cost and effort)?</blockquote><div><br></div><div>As was mentioned upthread, it would be really useful to break this down into "what I expect/want to happen" and "how confident am I that this is what the compiler is actually required to do, in the sense that as a responsible programmer I would rely on this in production code".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">    If<br>
people could comment on that concretely, e.g. for each of the<br>
questions of the survey, that would be really helpful.<br>
<br>
A tighter semantics does not necessarily mean a global change to C -<br>
it might just need a particular choice of existing or new options that<br>
makes sense for OS developers.</blockquote><div><br></div><div>Our users just need to be in communication with us about the issues they run into. We can't help them out if we don't know their problems. As useful as a questionnaire/poll is for getting a general feeling for things, without a concrete person (or persons) that can form a feedback loop for the implementation of any needed features, such features are unlikely to be implemented.</div><div><br></div><div>What is needed is a user that is keenly aware of their community's needs from the compiler and is willing to champion/consult for the implementation of any needed features. For example, maybe at, say, a Linux conference there is a face-to-face discussion involving many key stakeholders in the kernel, and a couple major pain points are identified. One motivated user could then bring the case of their entire community to us and we can discuss a clear direction. Tradeoffs will have to be made and that means bidirectional discussion is needed; ultimately a one-way communication like a questionnaire, even though it captures a broader audience, is insufficient (although it is a good first step, and might be a great starting point for the discussion at such a conference).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  And there are plenty of precedents<br>
here that have not involved the standards committee, e.g.<br>
fno-strict-aliasing.   In general, the standards committee prefers to<br>
codify existing practice, so establishing something workable in<br>
practice is the best first step in any case.<br>
<span class=""><font color="#888888"><br>
Peter<br>
</font></span><div class=""><div class="h5"><br>
<br>
><br>
><br>
> Michael<br>
><br>
><br>
><br>
> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On<br>
> Behalf Of Russell Wallace<br>
> Sent: Wednesday, July 01, 2015 22:22<br>
> To: Tim Northover<br>
> Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
> Subject: Re: [LLVMdev] C as used/implemented in practice: analysis of<br>
> responses<br>
><br>
><br>
><br>
> I am arguing in favor of a point, and I understand you disagree with it, but<br>
> I don't think I'm dismissing any use cases except a very small performance<br>
> increment. Furthermore, the compiler would still be free to perform such<br>
> optimisations where it can prove they won't break the program. That's not<br>
> all cases, to be sure, but at least we would then be back to the normal<br>
> scenario where over the years as the compiler gets smarter, things get<br>
> better, as opposed to monkey's paw optimisations which cause a smarter<br>
> compiler to make things worse.<br>
><br>
><br>
><br>
> On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>><br>
> wrote:<br>
><br>
> 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>
><br>
> Tim.<br>
><br>
><br>
><br>
> ---------------------------------------------------------------------<br>
> Intel Israel (74) Limited<br>
><br>
> 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.<br>
><br>
><br>
</div></div><div class=""><div class="h5">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>