On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric <dimi...@andric.com> wrote: > On 22 Aug 2018, at 18:45, Hans Wennborg <h...@chromium.org> wrote: >> >> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric <dimi...@andric.com> wrote: >>> On 22 Aug 2018, at 05:58, Wei Mi <w...@google.com> wrote: >>>> >>>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric <dimi...@andric.com> wrote: >>>> 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. >>>> >>>> >>>> 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? >>>> >>>> -Dimitry >>>> >>>> >>>> Sorry I missed the thread for quite a while. Dimitry, I am very confused >>>> because you reported the issue in >>>> https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be >>>> reverted and let llvm to generate cmxchg8b instruction for i486? >>> >>> Since it's been doing this for a number of years now, I don't think it >>> would be bad at all, at least not for FreeBSD. At least, a lot more effort >>> is needed to supply properly working atomic libcalls for 64 bit values on >>> i386. (They can't be implemented without at least a bit of kernel >>> assistance.) >> >> According to the release schedule we should tag RC2 today. Do you >> think there's any chance of getting this figured out by today? > > Since I'm testing on FreeBSD 11.x, and that will take quite a while to get > any new changes, I'd say it's safer to revert for now, at least on the > branch. At least then I can build and test the RCs on i386-freebsd. :)
I've reverted on trunk in r340666 and merged to the 7.0 branch in r340667. Also +Craig fyi for X86. Unfortunately this happened after RC2 which was tagged yesterday, but perhaps you can do a test run against the tip of the branch, and then later RC3 of coures? Also, is there a bug filed somewhere to track fixing the FreeBSD side? It would be great if we could reinstate this patch again before the next release. Thanks, Hans _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
