svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:
> On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
> > The number came out from an old posting involving buildworld times, which I can???t find now :(.
> > Things seem to have changed a lot: it was surely using GCC back then, I don???t believe clang does much distinction about 486 at all.
> > 
> > BTW, does it make sense to keep i586 in the configuration still? Both i486 and i586 were once removed but later re-instated in r205336.
> > 
> What did make significant impact on 32bit shared libraries some time ago
> was to compile them with -mtune=i686. Default PIC prologue effectively
> neutered return stack predictor, adding uneccessary overhead to already
> expensive PIC code. I think that this is even measureable, i.e. it might
> give >= 5% of difference.
> 
> I did not rechecked modern compilers WRT the generated PIC code, but I doubt
> that the thing changed recently.
> 
> Several notes: -mtune is not -march, i.e. the code would be still targeted
> for 486 instruction set, but scheduling is optimized for more modern CPUs.
> Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
> as request for scheduling for generic modern CPUs.  We already compile
> 32bit compat libs on amd64 with -march=i686.
> 
> Working on this stuff would be much more useful than tweaking kernel config
> for CPU detection.

Hmm, I originally wanted to use -mtune=i686 (spelled as -mcpu=pentiumpro) on
i386 builds for this reason, but I removed it at bde@'s request in r125252.
I would be happy to go back to adding -mtune for i386 when CPUTYPE isn't
specified.

-- 
John Baldwin