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
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
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
