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

On 22 Aug 2018, at 18:45, Hans Wennborg <hans at chromium.org>
wrote:
> 
> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric <dimitry at
andric.com> wrote:
>> On 22 Aug 2018, at 05:58, Wei Mi <wmi at google.com> wrote:
>>> 
>>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric <dimitry at
andric.com> 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?
>>> 
>>> -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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180823/a5585263/attachment.sig>

On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 22 Aug 2018, at 18:45, Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric <dimitry at
andric.com> wrote:
>>> On 22 Aug 2018, at 05:58, Wei Mi <wmi at google.com> wrote:
>>>>
>>>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric <dimitry at
andric.com> 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?
>>>>
>>>> -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

On 25 Aug 2018, at 00:51, Hans Wennborg <hans at chromium.org>
wrote:
> 
> On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric <dimitry at
andric.com> wrote:
>> On 22 Aug 2018, at 18:45, Hans Wennborg <hans at chromium.org>
wrote:
>>> 
>>> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric <dimitry at
andric.com> wrote:
>>>> On 22 Aug 2018, at 05:58, Wei Mi <wmi at google.com>
wrote:
...
>>>>> 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.
I've now filed <https://bugs.freebsd.org/230888>.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180825/0b2454df/attachment.sig>