llvm dev - Jul 2015 - [LLVMdev] C as used/implemented in practice: analysis of responses

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.

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<mailto:t.p.northover at gmail.com>> wrote:
On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at
gmail.com<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/0de0e8fa/attachment.html>

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
>

On 2 July 2015 at 11:17, Kuperstein, Michael M
<michael.m.kuperstein at intel.com> wrote:
> This isn’t an llvm-dev issue, it’s a standards committee issue.
Bingo!

--renato

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>

On 07/02/2015 03:17 AM, Kuperstein, Michael M wrote:
> You want to redefine ["won't break the program"], 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.
      This work has already been done in Annex L of the C standard, 
which provides an optional stricter abstract machine.  As far as I know, 
no implementations have attempted to support Annex L yet.
> Point is – I think you’re barking up the wrong tree.
>
> This isn’t an llvm-dev issue, it’s a standards committee issue.
      Because the standards work has been done, the ball is back in the 
implementations' court.  That doesn't mean Annex L should be the default
behavior.  It would be nice to have it as an option, though.

					David

On 07/02/2015 04:44 PM, David Keaton wrote:
> On 07/02/2015 03:17 AM, Kuperstein, Michael M wrote:
>> You want to redefine ["won't break the program"], 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.
>
>      This work has already been done in Annex L of the C standard, 
> which provides an optional stricter abstract machine.  As far as I 
> know, no implementations have attempted to support Annex L yet.
Do you have a link to the relevant text?  I've never heard of this, and 
a quick google search doesn't turn up anything relevant. Wikipedia knows 
about a set of "analyzability features", but that doesn't sounds
like
what you're talking about?
>
>> Point is – I think you’re barking up the wrong tree.
>>
>> This isn’t an llvm-dev issue, it’s a standards committee issue.
>
>      Because the standards work has been done, the ball is back in the 
> implementations' court.  That doesn't mean Annex L should be the 
> default behavior.  It would be nice to have it as an option, though.
>
>                     David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev