Re: reordering of trapping operations and volatile

2022-01-21 Thread Martin Uecker via Gcc
Am Dienstag, den 18.01.2022, 09:31 +0100 schrieb Richard Biener: > On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote: > > Hello, > > > > On Sat, 15 Jan 2022, Martin Uecker wrote: > > > > > > Because it interferes with existing optimisations. An explicit > > > > checkpoint has a clear me

Re: reordering of trapping operations and volatile

2022-01-18 Thread Richard Biener via Gcc
On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote: > > Hello, > > On Sat, 15 Jan 2022, Martin Uecker wrote: > > > > Because it interferes with existing optimisations. An explicit > > > checkpoint has a clear meaning. Using every volatile access that way > > > will hurt performance of code

Re: reordering of trapping operations and volatile

2022-01-17 Thread Michael Matz via Gcc
Hello, On Sat, 15 Jan 2022, Martin Uecker wrote: > > Because it interferes with existing optimisations. An explicit > > checkpoint has a clear meaning. Using every volatile access that way > > will hurt performance of code that doesn't require that behaviour for > > correctness. > > This is w

Re: reordering of trapping operations and volatile

2022-01-16 Thread Martin Uecker via Gcc
Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning: > > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > > > On 1/14/22 07:58, Paul Koning via Gcc wrote: > > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc > > > > wrote: > > > > > > > > > ... > > > > But right now that's equ

Re: reordering of trapping operations and volatile

2022-01-15 Thread Paul Koning via Gcc
> On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > On 1/14/22 07:58, Paul Koning via Gcc wrote: >>> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: >>> ... >>> But right now that's equivalent to making it observable, >>> because we don't have any other terms than observable

Re: reordering of trapping operations and volatile

2022-01-15 Thread Martin Sebor via Gcc
On 1/14/22 07:58, Paul Koning via Gcc wrote: On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: Hello, On Thu, 13 Jan 2022, Martin Uecker wrote: Handling all volatile accesses in the very same way would be possible but quite some work I don't see much value in. I see some value.

Re: reordering of trapping operations and volatile

2022-01-15 Thread Martin Uecker via Gcc
Am Samstag, den 15.01.2022, 16:33 + schrieb Jonathan Wakely: > On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote: > > > Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely: > > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, > > wrote: > > > > Hello, > > > > > > > > On Thu, 13

Re: reordering of trapping operations and volatile

2022-01-15 Thread Jonathan Wakely via Gcc
On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote: > Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely: > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, > wrote: > > > > > Hello, > > > > > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > > > > > Handling all volatile acce

Re: reordering of trapping operations and volatile

2022-01-15 Thread Martin Uecker via Gcc
Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely: > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote: > > > Hello, > > > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > > > Handling all volatile accesses in the very same way would be > > > > > > possible but quite

Re: reordering of trapping operations and volatile

2022-01-14 Thread Jonathan Wakely via Gcc
On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote: > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > Handling all volatile accesses in the very same way would be > > > > > possible but quite some work I don't see much value in. > > > > > > > > I see some value. > > > > > >

Re: reordering of trapping operations and volatile

2022-01-14 Thread Martin Uecker via Gcc
Am Freitag, den 14.01.2022, 14:15 + schrieb Michael Matz: > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: ... > > > I think to define this > > > all rigorously seems futile (you need a new > > > category between observable and UB), so it comes > > > down to compiler QoI on a case b

Re: reordering of trapping operations and volatile

2022-01-14 Thread Paul Koning via Gcc
> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: > > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > Handling all volatile accesses in the very same way would be > possible but quite some work I don't see much value in. I see some value. But

Re: reordering of trapping operations and volatile

2022-01-14 Thread Michael Matz via Gcc
Hello, On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > Handling all volatile accesses in the very same way would be > > > > possible but quite some work I don't see much value in. > > > > > > I see some value. > > > > > > But an alternative could be to remove volatile > > > from the observ

Re: reordering of trapping operations and volatile

2022-01-13 Thread Martin Uecker via Gcc
Am Donnerstag, den 13.01.2022, 16:45 + schrieb Michael Matz: > Hello, > > On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote: > > > > Handling all volatile accesses in the > > > very same way would be possible but quite some work I don't > > > see much value in. > > > > I see some value. > >

Re: reordering of trapping operations and volatile

2022-01-13 Thread Michael Matz via Gcc
Hello, On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote: > > Handling all volatile accesses in the > > very same way would be possible but quite some work I don't > > see much value in. > > I see some value. > > But an alternative could be to remove volatile > from the observable behavior in

Re: reordering of trapping operations and volatile

2022-01-11 Thread Martin Uecker via Gcc
Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener: > On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote: > > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > > > Am Montag, den 10.01.2022, 10:04 +0100 sc

Re: reordering of trapping operations and volatile

2022-01-11 Thread David Brown
On 11/01/2022 08:11, Richard Biener via Gcc wrote: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: >> > > I realize that UB in a + b isn't (usually) observable but > UB resulting in traps are. > > So I'm still wondering why you think that 'volatile' makes > a critical difference we oug

Re: reordering of trapping operations and volatile

2022-01-11 Thread Richard Biener via Gcc
On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote: > > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: > > Hi Richard, > > > > > > For volatile, it seem

Re: reordering of trapping operations and volatile

2022-01-11 Thread Martin Uecker via Gcc
Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: Hi Richard, > > > > For volatile, it seems this would need some tweaks. > > > > > > Yes, likewise when re-or

Re: reordering of trapping operations and volatile

2022-01-10 Thread Richard Biener via Gcc
On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: > > On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc > > wrote: > > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > > > > On Sat, Jan 8, 2022 at 12:33 A

Re: reordering of trapping operations and volatile

2022-01-10 Thread Martin Uecker via Gcc
Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: > On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote: > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc > > > wrote: > > > > Hi Richard, > > > > >

Re: reordering of trapping operations and volatile

2022-01-10 Thread Richard Biener via Gcc
On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote: > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc > > wrote: > > > > > > Hi Richard, > > > > > > I have a question regarding reodering of volatile > > > accesse

Re: reordering of trapping operations and volatile

2022-01-08 Thread Martin Uecker via Gcc
Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote: > > > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumption (and hope) was that compile

Re: reordering of trapping operations and volatile

2022-01-08 Thread Andrew Pinski via Gcc
On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote: > > > Hi Richard, > > I have a question regarding reodering of volatile > accesses and trapping operations. My initial > assumption (and hope) was that compilers take > care to avoid creating traps that are incorrectly > ordered relativ

Re: reordering of trapping operations and volatile

2022-01-08 Thread Eric Botcazou
> Most C programmers would assume that volatile accesses already > provides this guarantee, so actually doing so would be good. I'm a little skeptical of this statement: if it was true, how come the most recent version of the standard does not provide it 30 years after the language was first sta

Re: reordering of trapping operations and volatile

2022-01-08 Thread Martin Uecker via Gcc
Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown: > On 08/01/2022 09:32, Martin Uecker via Gcc wrote: > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumption (and hope) was that compilers take > > care to

Re: reordering of trapping operations and volatile

2022-01-08 Thread Martin Uecker via Gcc
Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou: > > Yes, although I think potentially trapping ops > > are not moved before calls (as this would be > > incorrect). So do you think it would be feasable > > to prevent this for volatile too? > > Feasible probably, but why would this b

Re: reordering of trapping operations and volatile

2022-01-08 Thread David Brown
On 08/01/2022 09:32, Martin Uecker via Gcc wrote: > > Hi Richard, > > I have a question regarding reodering of volatile > accesses and trapping operations. My initial > assumption (and hope) was that compilers take > care to avoid creating traps that are incorrectly > ordered relative to observa

Re: reordering of trapping operations and volatile

2022-01-08 Thread Eric Botcazou
> Yes, although I think potentially trapping ops > are not moved before calls (as this would be > incorrect). So do you think it would be feasable > to prevent this for volatile too? Feasible probably, but why would this be desirable in C? It's not Java! -- Eric Botcazou

Re: reordering of trapping operations and volatile

2022-01-08 Thread Marc Glisse
On Sat, 8 Jan 2022, Martin Uecker via Gcc wrote: Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener: On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker wrote: Hi Richard, thank you for your quick response! I have a question regarding reodering of volatile accesses and tra

Re: reordering of trapping operations and volatile

2022-01-08 Thread Martin Uecker via Gcc
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener: > On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker > wrote: > > Hi Richard, thank you for your quick response! > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumpt

Re: reordering of trapping operations and volatile

2022-01-08 Thread Richard Biener via Gcc
On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker wrote: > >Hi Richard, > >I have a question regarding reodering of volatile >accesses and trapping operations. My initial >assumption (and hope) was that compilers take >care to avoid creating traps that are incorrectly >ordered relative to o