Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 22 Aug 2018, at 05:58, Wei Mi wrote: > > On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric wrote: > On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev > 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 + (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.) -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
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric wrote: > On 22 Aug 2018, at 05:58, Wei Mi wrote: >> >> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric wrote: >> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev >> 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 + (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? Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [7.0.0 Release] rc2 has been tagged
Dear testers, 7.0.0-rc2 was just tagged (from branch revision r340437). There have been a bunch of merges since rc1, and hopefully many of the issues with the previous candidate are fixed in this one. Please run the test script, share the results, and upload binaries. I will publish source tarballs, docs, and binaries on the web page once they're ready. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 22 Aug 2018, at 18:45, Hans Wennborg wrote: > > On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric wrote: >> On 22 Aug 2018, at 05:58, Wei Mi wrote: >>> >>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric wrote: >>> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev >>> 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 + (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. :) -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
