[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Joerg Sonnenberger via llvm-dev]

On Fri, Aug 17, 2018 at 10:27:36PM +0200, Dimitry Andric wrote:
> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
> >> This is a regression caused by https://reviews.llvm.org/rL323281:
> >> 
> >> ------------------------------------------------------------------------
> >> r323281 | wmi | 2018-01-23 23:27:57 +0000 (Tue, 23 Jan 2018) | 12 lines
> >> 
> >> Adjust MaxAtomicInlineWidth for i386/i486 targets.
> >> 
> >> This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
> >> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
> >> i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
> >> So in this patch MaxAtomicInlineWidth is reset as follows:
> >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
> >> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
> >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
> > 
> > This seems to be somewhat undesirable. Does *anyone* care about real
> > i386 support at this point? NetBSD certainly doesn't and I think we are
> > already the odd man for a number of cases like this.
> 
> 
> Yes, and since this causes quite a number of regressions for us, I would
> really prefer this revision to be reverted, at least in the 7.0.0
> branch.  I have already reverted it locally in our FreeBSD project
> branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
> this?

Don't get me wrong, I think the original behavior is wrong as well. It
seems to me we should unconditionally assume support for cmpxchg, but
not of cmpxchg8b. Accordingly, MaxAtomicInlineWidth should be 32 by
default, unless Pentium+ is explicitly targetted.

Joerg