[llvm] r310583 - [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.

Chupina, Olga via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 17 06:11:48 PDT 2017


Hi,

I'm going to recommit the patch.
I didn't manage to reproduce the timeout.
Please let me know if you have any objections.

Thanks,
Olga

From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf Of Chupina, Olga via llvm-commits
Sent: Wednesday, 27 September, 2017 2:25 PM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>; Chandler Carruth <chandlerc at gmail.com>; Bozhenov, Nikolai <nikolai.bozhenov at intel.com>
Cc: nd <nd at arm.com>; LLVM Commits <llvm-commits at lists.llvm.org>
Subject: RE: [llvm] r310583 - [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.

Hi Evgeny,

No, I could not reproduce the timeout. Yes, it is safe.
And we also see no stability issues in our testing.
Currently I'm updating lit tests and plan to recommit on the next week.

Thanks,
Olga



From: Evgeny Astigeevich [mailto:Evgeny.Astigeevich at arm.com]
Sent: Tuesday, 26 September, 2017 10:37 PM
To: Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>>; Bozhenov, Nikolai <nikolai.bozhenov at intel.com<mailto:nikolai.bozhenov at intel.com>>; Chupina, Olga <olga.chupina at intel.com<mailto:olga.chupina at intel.com>>
Cc: nd <nd at arm.com<mailto:nd at arm.com>>; LLVM Commits <llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>>
Subject: RE: [llvm] r310583 - [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.

Hi,

Did you manage to reproduce the timeout? Is it safe to enable it?
The optimization works for Arm architectures as well. We see ~16% performance improvement in our benchmarks on Cortex-M7. In fact we found this when we got regressions because of the disabled optimization.
We did not have any stability issues when the optimization was enabled.

Thanks,
Evgeny


From: Chupina, Olga
Sent: Thursday, 31 August, 2017 11:25 AM
To: 'Chandler Carruth' <chandlerc at gmail.com>
Cc: 'llvm-commits at lists.llvm.org' <llvm-commits at lists.llvm.org>; Bozhenov, Nikolai <nikolai.bozhenov at intel.com>
Subject: RE: [llvm] r310583 - [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.

Hi Chandler,

Could you please provide more information on the fail you've observed?

Thanks,
Olga

From: Chupina, Olga
Sent: Wednesday, 23 August, 2017 3:28 PM
To: Bozhenov, Nikolai <nikolai.bozhenov at intel.com<mailto:nikolai.bozhenov at intel.com<mailto:nikolai.bozhenov%20at%20intel.com>>>; Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com<mailto:chandlerc%20at%20gmail.com>>>
Cc: llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org<mailto:llvm-commits%20at%20lists.llvm.org>>
Subject: RE: [llvm] r310583 - [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.

Hi Chandler,

I'm investigating the issue with core.c file and could not reproduce the problem you've mentioned.
I've checked out  sources for stable-1.0 branch and build it with:
$ ./configure --cc=<path-to-my-clang>
$ make

Here are my compile line and clang version:

$ clang -I/tmpdir/qemu/slirp -I. -I/tmpdir/qemu -I/tmpdir/qemu/fpu -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing  -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-definition -Wtype-limits -I/usr/include/libpng15 -I/tmpdir/qemu/libcacard -I/usr/include/nss3 -I/usr/include/nspr4   -DTARGET_PHYS_ADDR_BITS=64 -I.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -MMD -MP -MT ide/core.o -MF ide/core.d -O2 -g  -c -o ide/core.o /tmpdir/qemu/hw/ide/core.c

$ clang -v
clang version 6.0.0 (trunk 310583)
Target: x86_64-unknown-linux-gnu
Thread model: posix

I also checked qemu trunk version, it also has no problems. Compilation time is the same for r310582 and r310583.

Could you please provide additional information on how to reproduce the timeout issue?

Thanks,
Olga

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171017/c984a1f0/attachment.html>


More information about the llvm-commits mailing list