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

[Peter Sewell]

On 2 July 2015 at 22:12, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> 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".

To some extent we have this, implicitly, in the textual comments, and
in the expertise of the respondents.  We looked at the detail and tone
of all that before writing the summaries; it's just not quantified.

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

Yes, absolutely - that questionnaire and this mailing list
conversation is only intended as a first step.  Still, if we can get
with this kind of discussion to at least some plausible approaches for
addressing some of the pain points that are already clear, that would
help a lot in getting things started and identifying the right people
to talk to.

thanks,
Peter


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