[LLVMdev] C as used/implemented in practice: analysis of responses

[Sean Silva]

On Thu, Jul 2, 2015 at 4:52 AM, Peter Sewell <Peter.Sewell at cl.cam.ac.uk>
wrote:

> On 2 July 2015 at 11:17, Kuperstein, Michael M
> <michael.m.kuperstein at intel.com> wrote:
> > We already perform optimizations only when the compiler can prove they
> won’t
> > break the program.
> >
> > 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”.
> >
> >
> >
> > 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.
> >
> >
> >
> > Point is – I think you’re barking up the wrong tree.
> >
> > This isn’t an llvm-dev issue, it’s a standards committee issue.
>
> This thread has diverged a bit since I was last here, and I'm not the
> one you were responding to above.  But as far as I'm concerned, the
> question for the LLVM community (and similarly the GCC community and
> other compiler developers) is, for each of the ways in which systems
> code and OS developers clearly are relying on behaviour that you don't
> think you currently support, what is the least-runtime-cost and
> least-effort way of doing so (and what is that cost and effort)?


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".


>     If
> people could comment on that concretely, e.g. for each of the
> questions of the survey, that would be really helpful.
>
> A tighter semantics does not necessarily mean a global change to C -
> it might just need a particular choice of existing or new options that
> makes sense for OS developers.


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.

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).

-- Sean Silva


>   And there are plenty of precedents
> here that have not involved the standards committee, e.g.
> fno-strict-aliasing.   In general, the standards committee prefers to
> codify existing practice, so establishing something workable in
> practice is the best first step in any case.
>
> Peter
>
>
> >
> >
> > Michael
> >
> >
> >
> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On
> > Behalf Of Russell Wallace
> > Sent: Wednesday, July 01, 2015 22:22
> > To: Tim Northover
> > Cc: llvmdev at cs.uiuc.edu
> > Subject: Re: [LLVMdev] C as used/implemented in practice: analysis of
> > responses
> >
> >
> >
> > 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.
> >
> >
> >
> > On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <t.p.northover at gmail.com>
> > wrote:
> >
> > On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com>
> wrote:
> >> Why do you say spin?
> >
> > You're dismissing all use-cases other than this very narrow one I'd
> > (with my own spin) characterise as "Do What I Mean, I Can't Be
> > Bothered To Get My Code Right". Fair enough, you're arguing in favour
> > of a point; but it's not one I agree with.
> >
> > Tim.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/21840198/attachment.html>