bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, mattiase@acm.org, andrea_corallo@yahoo.it,
>  42147@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 5 Jul 2020 01:28:46 -0700
> 
> On 7/4/20 7:38 PM, Eli Zaretskii wrote:
> 
> >   . which other projects use this non-standard instruction set?
> 
> Wait a minute, SSE2 is not "non-standard". It was introduced in 2000 as part 
> of
> the evolving Intel/AMD x86 instruction set, and is supported by pretty much
> every x86-compatible chip that first shipped after 2003-or-so and that is a
> plausible candidate for Emacs.  (Stefan's old laptop uses a circa-2001 chip.)

That's not what I meant: I meant "non-standard" in the sense that the
compiler doesn't generate these instructions by default when dealing
with FP calculations.

> To get back to your question, many software projects already require SSE2 on
> x86. This includes Chromium since build 35 (2014), Firefox since Firefox 53
> (2017), and WebKit2GTK since version 2.24.0 (2019). Since Emacs links to
> WebKit2GTK by default, recent Emacs by default already requires SSE2 on x86.
> Similarly, many Gnome applications require SSE2 on x86, as they also link to
> WebKit2GTK.
> 
> Among proprietary systems, Mac OS X on x86 (2006-2011) always required SSE2, 
> and
> MS-Windows development platforms have been requiring SSE2 by default since 
> 2012,
> which means pretty much every application built for 32-bit MS-Windows requires
> SSE2 nowadays. Also, all supported MS-Windows operating systems have required
> SSE2 since 2018, which is when Microsoft pushed out an update for MS-Windows 7
> that required SSE2.

Thanks, I knew all that.  Emacs is not an OS, it's an application, and
the issue here is about using these instructions for FP calculations,
not for anything else.  That was what I was asking about: applications
doing FP math.

> >   . why didn't GCC folks made SSE2 the default output?
> 
> I suspect they think x86 is on its way out and not worth worrying about.

Then why won't we do the same, and simply ignore the issue?  We have
enough real development and maintenance work on our hands.  Making
non-trivial change in the code we produce for Emacs, for the benefit
of (at best) insignificant speed improvement on a dying platform,
while risking breakage for at least some systems, is not a good use of
our scarce resources, IMO.