On 2021-07-17 06:32, Jonathan Wakely via Gcc-patches wrote:
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote: On Fri, 16
Jul 2021 at 20:26, Matthias Kretz wrote: On Friday, 16
July 2021 18:54:30 CEST Jonathan Wakely wrote: On Fri,
On 7/19/21 5:41 AM, Richard Earnshaw wrote:
On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote:
On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote:
On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
If somebody writes
On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote:
On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote:
On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
If somebody writes a library with `keep_apart` in the public AP
On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote:
> On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
> > On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> > > If somebody writes a library with `keep_apart` in the public API/ABI
> then
> > > you're right.
> >
> > Yes, it's fin
On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
> On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> > If somebody writes a library with `keep_apart` in the public API/ABI then
> > you're right.
>
> Yes, it's fine if those constants don't affect anything across module
> boundaries
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote:
> On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote:
> > On Fri, 16 Jul 2021 at 20:26, Matthias Kretz wrote:
> > > On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> > > > On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
>
On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote:
> On Fri, 16 Jul 2021 at 20:26, Matthias Kretz wrote:
> > On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> > > On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> > > > Adjusting them based on tuning would certainly simpli
On Fri, Jul 16, 2021 at 3:37 PM Matthias Kretz wrote:
> On Friday, 16 July 2021 19:20:29 CEST Noah Goldstein wrote:
> > On Fri, Jul 16, 2021 at 11:12 AM Matthias Kretz wrote:
> > > I don't understand how this feature would lead to false sharing. But
> maybe
> > > I
> > > misunderstand the spatia
On Fri, 16 Jul 2021 at 20:26, Matthias Kretz wrote:
>
> On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> > On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> > > Adjusting them based on tuning would certainly simplify a significant use
> > > case, perhaps the only reasonable use.
On Friday, 16 July 2021 19:20:29 CEST Noah Goldstein wrote:
> On Fri, Jul 16, 2021 at 11:12 AM Matthias Kretz wrote:
> > I don't understand how this feature would lead to false sharing. But maybe
> > I
> > misunderstand the spatial prefetcher. The first access to one of the two
> > cache
> > lines
On Friday, 16 July 2021 18:54:30 CEST Jonathan Wakely wrote:
> On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> > Adjusting them based on tuning would certainly simplify a significant use
> > case, perhaps the only reasonable use. Cases more concerned with ABI
> > stability probably shouldn't
On Fri, Jul 16, 2021, 12:54 PM Jonathan Wakely wrote:
> On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> > Adjusting them based on tuning would certainly simplify a significant use
> > case, perhaps the only reasonable use. Cases more concerned with ABI
> > stability probably shouldn't use t
On Fri, Jul 16, 2021 at 11:12 AM Matthias Kretz wrote:
> On Friday, 16 July 2021 04:41:17 CEST Jason Merrill via Gcc-patches wrote:
> > > Currently the patch does not adjust the values based on -march, as in
> JF's
> > > proposal. I'll need more guidance from the ARM/AArch64 maintainers
> about
On Fri, 16 Jul 2021 at 16:33, Jason Merrill wrote:
> Adjusting them based on tuning would certainly simplify a significant use
> case, perhaps the only reasonable use. Cases more concerned with ABI
> stability probably shouldn't use them at all. And that would mean not
> needing to worry about the
On Fri, Jul 16, 2021, 11:12 AM Matthias Kretz wrote:
> On Friday, 16 July 2021 04:41:17 CEST Jason Merrill via Gcc-patches wrote:
> > > Currently the patch does not adjust the values based on -march, as in
> JF's
> > > proposal. I'll need more guidance from the ARM/AArch64 maintainers
> about
>
On Friday, 16 July 2021 04:41:17 CEST Jason Merrill via Gcc-patches wrote:
> > Currently the patch does not adjust the values based on -march, as in JF's
> > proposal. I'll need more guidance from the ARM/AArch64 maintainers about
> > how to go about that. --param l1-cache-line-size is set based
On 16/07/2021 12:17, Jonathan Wakely via Gcc-patches wrote:
On Fri, 16 Jul 2021 at 03:51, Noah Goldstein wrote:
On intel x86 systems with a private L2 cache the spatial prefetcher
can cause destructive interference along 128 byte aligned boundaries.
https://www.intel.com/content/dam/www/publi
On Fri, 16 Jul 2021 at 03:42, Jason Merrill via Libstdc++
wrote:
> > diff --git a/libstdc++-v3/include/std/version
> > b/libstdc++-v3/include/std/version
> > index 27bcd32cb60..d5e155db48b 100644
> > --- a/libstdc++-v3/include/std/version
> > +++ b/libstdc++-v3/include/std/version
> > @@ -140,6 +1
On Fri, 16 Jul 2021 at 03:51, Noah Goldstein wrote:
> On intel x86 systems with a private L2 cache the spatial prefetcher
> can cause destructive interference along 128 byte aligned boundaries.
> https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimizatio
On Thu, Jul 15, 2021 at 10:41 PM Jason Merrill via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Adding CCs that got lost in the initial mail.
>
> On Thu, Jul 15, 2021 at 10:36 PM Jason Merrill wrote:
>
> > The last missing piece of the C++17 standard library is the hardware
> > intereference s
Adding CCs that got lost in the initial mail.
On Thu, Jul 15, 2021 at 10:36 PM Jason Merrill wrote:
> The last missing piece of the C++17 standard library is the hardware
> intereference size constants. Much of the delay in implementing these has
> been due to uncertainty about what the right v
21 matches
Mail list logo
