On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-...@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.
It's also affecting i486, which is still the default -march value on FreeBSD. Note that clang has been silently generating cmpxchg8b's for years now, even for the i486 target, but I have never seen any complaint about crashes due to this. So basically everybody is running i586 or higher, in practice... -Dimitry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
