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

[Peter Sewell]

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