Page MenuHomePhabricator
Feed Advanced Search

Mon, Sep 16

davezarzycki accepted D67171: LLVM_COMPILE_FLAGS also applies to C files.

r371173 and r371521

Mon, Sep 16, 10:31 PM · Restricted Project
davezarzycki closed D67171: LLVM_COMPILE_FLAGS also applies to C files.
Mon, Sep 16, 10:31 PM · Restricted Project
davezarzycki committed rG73f2dbb7d24d: [git-llvm] Do not reinvent `@{upstream}` (take 2) (authored by davezarzycki).
[git-llvm] Do not reinvent `@{upstream}` (take 2)
Mon, Sep 16, 9:46 PM
davezarzycki closed D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).

r372070

Mon, Sep 16, 9:43 PM · Restricted Project
davezarzycki committed rL372070: [git-llvm] Do not reinvent `@{upstream}` (take 2).
[git-llvm] Do not reinvent `@{upstream}` (take 2)
Mon, Sep 16, 9:42 PM

Fri, Sep 13

davezarzycki added a comment to D66775: [libclang] Expose abort()-ing fatal error handler.

This breaks one of the clang unit tests on Fedora 30 (x86_64). Can we revert or fix this?

FAIL: Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler (19745 of 51413)
******************** TEST 'Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler' FAILED ********************
Note: Google Test filter = LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from LibclangParseTest
[ RUN      ] LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler
LLVM ERROR: #pragma clang __debug llvm_fatal_error
Fri, Sep 13, 2:29 AM · Restricted Project

Thu, Sep 12

davezarzycki added a comment to D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).

Works for me, but let's confirm with @thakis

Thu, Sep 12, 1:02 AM · Restricted Project

Wed, Sep 11

davezarzycki committed rGc167402183aa: [WebAssembly] Add REQUIRES to test (authored by davezarzycki).
[WebAssembly] Add REQUIRES to test
Wed, Sep 11, 11:52 PM
davezarzycki committed rL371710: [WebAssembly] Add REQUIRES to test.
[WebAssembly] Add REQUIRES to test
Wed, Sep 11, 11:51 PM
davezarzycki committed rGb250d5ff5e7c: [LLDB] Do not try to canonicalize gethostname() result (authored by davezarzycki).
[LLDB] Do not try to canonicalize gethostname() result
Wed, Sep 11, 1:33 AM
davezarzycki committed rL371596: [LLDB] Do not try to canonicalize gethostname() result.
[LLDB] Do not try to canonicalize gethostname() result
Wed, Sep 11, 1:33 AM
davezarzycki added a comment to D67230: Remove call to obsolete gethostbyname, using getaddrinfo.

Great. See: r371596

Wed, Sep 11, 1:33 AM · Restricted Project, Restricted Project

Tue, Sep 10

davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

I don't know what the long-term plans for this script are.

The only way for us to enforce linear history on GitHub at the moment is to mandate the use of the script unfortunately.

Tue, Sep 10, 11:04 PM · Restricted Project
davezarzycki committed rGfef1cb1c971e: [CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler (authored by davezarzycki).
[CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler
Tue, Sep 10, 7:20 AM
davezarzycki added a comment to D67171: LLVM_COMPILE_FLAGS also applies to C files.

Hi @uabelho – Try r371521

Tue, Sep 10, 7:18 AM · Restricted Project
davezarzycki committed rL371521: [CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler.
[CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler
Tue, Sep 10, 7:18 AM
davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

Upon re-reading this sounds a bit accusatory. That's not how I meant this, apologies for that! I understand you're solving a problem you're having and that's a fine thing to do of course. I'm just trying to say that this particular approach (unintentionally!) caused a problem for me, and I imagine for many people using the monorepo.

I'm trying to brainstorm ways forward that solve your problem without breaking me.

Tue, Sep 10, 7:02 AM · Restricted Project
davezarzycki created D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).
Tue, Sep 10, 1:44 AM · Restricted Project
davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

I took the responsibility of reverting in r371480, since I approved this revision without anticipating the behavior change.

To add some more words, previously we could git checkout -b foo, hack a bit commit, and run this script. Now this requires additional, long flags. I don't think making a corner case work that nobody noticed being broken for many months is worth making everything more inconvenient for everyone.

This is a very good point. How do we move forward though?
With the migration to GitHub around the corner, I think it'll be important to have git llvm behaves as much as possible as thin wrapper on top of git (in case you don't know git llvm push will be mandatory to push to LLVM on GitHub, as far as I know).

Tue, Sep 10, 12:38 AM · Restricted Project

Sun, Sep 8

davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

The script doesn't have the ability to specify the name of the remote server. That being said, the script is only designed to work with one backend server due to how it hides SVN and in the future how it will hide GitHub status check magic.

Sun, Sep 8, 8:50 PM · Restricted Project
davezarzycki closed D67262: [git-llvm] Do not reinvent `@{upstream}`.
  1. Working with and configuring upstream branches is fundamental to using git.
  2. It was a mistake for the git-llvm script to assume that the remote named "origin" is the official LLVM repository. For many people, "origin" is probably correct, but for many others, and the remote named origin depends on which repository was cloned first.
  3. Your local branch isn't setup correctly. You can fix that with git branch --set-upstream-to=origin/master (assuming that origin is the correct name of the remote server in your git repository).
  4. When you use git branch or git checkout, please remember to use --track if that is what you want/need.
Sun, Sep 8, 4:10 AM · Restricted Project

Fri, Sep 6

davezarzycki committed rG7faffd544b16: [git-llvm] Do not reinvent `@{upstream}` (authored by davezarzycki).
[git-llvm] Do not reinvent `@{upstream}`
Fri, Sep 6, 11:47 PM
davezarzycki committed rL371290: [git-llvm] Do not reinvent `@{upstream}`.
[git-llvm] Do not reinvent `@{upstream}`
Fri, Sep 6, 11:47 PM
davezarzycki added a comment to D67230: Remove call to obsolete gethostbyname, using getaddrinfo.

This code is trying too hard and failing. Either the result of gethostname() is canonical or it is not. If it is not, then trying to canonicalize it is – for various reasons – a lost cause. For example, a given machine might have multiple network interfaces with multiple addresses per interface, each with a different canonical name. Separably, the result of HostInfoPosix::GetHostname() and latency thereof shouldn't depend on whether networking is up or down or what network the machine happened to be attached to at any given moment (like a laptop that travels between work and home).

Fri, Sep 6, 5:36 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D65884: [ARM] MVE Tail Predication.

I think this might have caused a regression (my git-bisect is nearly complete):

FAIL: LLVM :: CodeGen/ARM/O3-pipeline.ll (24373 of 51236)
******************** TEST 'LLVM :: CodeGen/ARM/O3-pipeline.ll' FAILED ********************
Script:
--
: 'RUN: at line 1';   /tmp/_update_lc/t/bin/llc -mtriple=arm -O3 -debug-pass=Structure < /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll -o /dev/null 2>&1 | grep -v "Verify generated machine code" | /tmp/_update_lc/t/bin/FileCheck /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll
--
Exit Code: 1
Fri, Sep 6, 2:19 AM · Restricted Project
davezarzycki created D67262: [git-llvm] Do not reinvent `@{upstream}`.
Fri, Sep 6, 1:20 AM · Restricted Project
davezarzycki committed rG412a8d7a8310: [CMake] LLVM_COMPILE_FLAGS also applies to C files (authored by davezarzycki).
[CMake] LLVM_COMPILE_FLAGS also applies to C files
Fri, Sep 6, 12:15 AM
davezarzycki committed rL371173: [CMake] LLVM_COMPILE_FLAGS also applies to C files.
[CMake] LLVM_COMPILE_FLAGS also applies to C files
Fri, Sep 6, 12:11 AM

Wed, Sep 4

davezarzycki updated the diff for D67171: LLVM_COMPILE_FLAGS also applies to C files.
Wed, Sep 4, 7:33 AM · Restricted Project
davezarzycki created D67171: LLVM_COMPILE_FLAGS also applies to C files.
Wed, Sep 4, 7:17 AM · Restricted Project
davezarzycki committed rL370846: Add myself and sort the list.
Add myself and sort the list
Wed, Sep 4, 12:54 AM

Sat, Aug 24

davezarzycki accepted D66700: [Wdocumentation] improve wording of a warning message.
Sat, Aug 24, 4:07 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D66700: [Wdocumentation] improve wording of a warning message.

Works for me. Thanks!

Sat, Aug 24, 4:07 AM · Restricted Project, Restricted Project
davezarzycki committed rG98bcf690ae03: [Testing] Unbreak r369830 (authored by davezarzycki).
[Testing] Unbreak r369830
Sat, Aug 24, 1:14 AM
davezarzycki committed rL369843: [Testing] Unbreak r369830.
[Testing] Unbreak r369830
Sat, Aug 24, 1:14 AM

Tue, Aug 20

davezarzycki committed rGb08884554f68: [PPC Docs] Remove duplicate info about __builtin_setrnd() (authored by davezarzycki).
[PPC Docs] Remove duplicate info about __builtin_setrnd()
Tue, Aug 20, 11:50 PM
davezarzycki committed rL369496: [PPC Docs] Remove duplicate info about __builtin_setrnd().
[PPC Docs] Remove duplicate info about __builtin_setrnd()
Tue, Aug 20, 11:49 PM

Aug 6 2019

davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

I don't think anybody is running doxygen over the Swift source right now, so I'll just escape the @ sign. That being said, can we improve this diagnostic? "command does not have an argument" is confusing when a given command does have an argument, just a malformed one. What do you think about "command must precede a word"? At least that gives a hint that the argument is not a "word" according to doxygen.

Aug 6 2019, 11:47 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

From the Swift language source (http://github.com/apple/swift):

Aug 6 2019, 12:57 AM · Restricted Project, Restricted Project

Aug 5 2019

davezarzycki added a comment to D62445: [test] Fix plugin tests.

Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a hack that should go away someday. Doing so requires that plugin dependencies either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked into the executables that load them and the plugin knows how to find them in the executable. In the case of the latter and on Mach-O platforms, this requires passing -bundle_loader $PATH_TO_EXECUTABLE to the linker when creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what needs to be done.

Aug 5 2019, 11:30 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D62445: [test] Fix plugin tests.

Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a hack that should go away someday. Doing so requires that plugin dependencies either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked into the executables that load them and the plugin knows how to find them in the executable. In the case of the latter and on Mach-O platforms, this requires passing -bundle_loader $PATH_TO_EXECUTABLE to the linker when creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what needs to be done.

Aug 5 2019, 11:11 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

Hello – This change seems to have exposed a bug in -Wdocumentation argument parsing. For example, this warns when it shouldn't(?):

Aug 5 2019, 3:19 AM · Restricted Project, Restricted Project

Jul 31 2019

davezarzycki committed rG4f1d893f9ec3: [Testing] Fix tests that break with read-only checkouts (authored by davezarzycki).
[Testing] Fix tests that break with read-only checkouts
Jul 31 2019, 11:42 PM
davezarzycki committed rL367519: [Testing] Fix tests that break with read-only checkouts.
[Testing] Fix tests that break with read-only checkouts
Jul 31 2019, 11:40 PM

Jul 15 2019

davezarzycki committed rG12400b97838d: [Testing] Add missing "REQUIRES: asserts" (authored by davezarzycki).
[Testing] Add missing "REQUIRES: asserts"
Jul 15 2019, 7:14 AM
davezarzycki committed rL366065: [Testing] Add missing "REQUIRES: asserts".
[Testing] Add missing "REQUIRES: asserts"
Jul 15 2019, 7:13 AM

Jul 4 2019

davezarzycki added a comment to D64200: [ELF] Allow placing non-string SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I just did a quick test of this patch and now stage two testing works (Fedora 30, x86-64)

Jul 4 2019, 5:51 AM · Restricted Project

Jul 3 2019

davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I can try -M (a.k.a. --print-map). Is there a simple failing test from the LLVM or clang test suite that would be enlightening to try it with?

Jul 3 2019, 8:45 AM · Restricted Project
davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

Well, as it turns out, -DLLVM_LDFLAGS is even less effective than the original CMAKE build options.

Jul 3 2019, 7:48 AM · Restricted Project
davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

As it turns out, stage 2 still fails on my workstation, but that's because -DCMAKE_EXE_LINKER_FLAGS=-Wl,-O0 -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-O0 does NOT work as one expects due to LLVM's cmake/modules/AddLLVM.cmake setting -Wl,-O3 *after* CMake's CMAKE_EXE_LINKER_FLAGS or CMAKE_SHARED_LINKER_FLAGS. I'm trying a new two stage build with -DLLVM_LDFLAGS=-Wl,-O0.

Jul 3 2019, 7:27 AM · Restricted Project
davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I'm doing a three-stage build, but perhaps not exactly the same way. I'd be surprised if it passes.

Jul 3 2019, 6:46 AM · Restricted Project
davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

Actually, the bug is narrower and doesn't require Swift (my build-and-test script placed the blame incorrectly). One just needs to build llvm+clang+lld after this change, then the following tests fail:

Jul 3 2019, 6:23 AM · Restricted Project
davezarzycki added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

This change breaks a ton of clang tests, albeit in the Swift fork of clang. Was this expected? If not, can we revert this for now?

Jul 3 2019, 6:06 AM · Restricted Project

Jun 20 2019

davezarzycki committed rGf237c7d411fa: [Testing] Dumping the graph requires assertions be enabled (authored by davezarzycki).
[Testing] Dumping the graph requires assertions be enabled
Jun 20 2019, 2:58 AM
davezarzycki committed rL363916: [Testing] Dumping the graph requires assertions be enabled.
[Testing] Dumping the graph requires assertions be enabled
Jun 20 2019, 2:57 AM

Jun 4 2019

davezarzycki committed rGc73c10a9bf1d: Unbreak my hasty "unbreak" cmake fix (authored by davezarzycki).
Unbreak my hasty "unbreak" cmake fix
Jun 4 2019, 4:34 AM
davezarzycki committed rL362492: Unbreak my hasty "unbreak" cmake fix.
Unbreak my hasty "unbreak" cmake fix
Jun 4 2019, 4:34 AM

Jun 3 2019

davezarzycki added a comment to D62720: AMDGPU/GFX10: V_CMPX_xxx instructions still have an omod operand.

Sorry for the stale copy-and-paste buffer noise. This did NOT break non-PIC builds.

Jun 3 2019, 6:46 AM · Restricted Project
davezarzycki added a comment to D62445: [test] Fix plugin tests.

This broke non-PIC builds. Fixed: r362399

Jun 3 2019, 6:46 AM · Restricted Project, Restricted Project
davezarzycki committed rG082d99f58cbe: Unbreak non-PIC builds after r362390 / D62720 (authored by davezarzycki).
Unbreak non-PIC builds after r362390 / D62720
Jun 3 2019, 6:40 AM
davezarzycki committed rL362399: Unbreak non-PIC builds after r362390 / D62720.
Unbreak non-PIC builds after r362390 / D62720
Jun 3 2019, 6:40 AM

May 22 2019

davezarzycki added a comment to D62174: [Analysis] Link library dependencies to Analysis plugins.

Fixed: r361399

May 22 2019, 8:47 AM · Restricted Project, Restricted Project
davezarzycki committed rGbe0e70dcde48: Unbreak non-PIC builds after r361340/D62174 (authored by davezarzycki).
Unbreak non-PIC builds after r361340/D62174
May 22 2019, 8:46 AM
davezarzycki committed rL361399: Unbreak non-PIC builds after r361340/D62174.
Unbreak non-PIC builds after r361340/D62174
May 22 2019, 8:45 AM
davezarzycki resigned from D43578: -ftime-report switch support in Clang.
May 22 2019, 6:54 AM
davezarzycki added a comment to D62174: [Analysis] Link library dependencies to Analysis plugins.

This breaks non-PIC builds. Was this planned or expected? Can we revert this until a fix is found?

May 22 2019, 5:45 AM · Restricted Project, Restricted Project

Mar 30 2019

davezarzycki added a comment to D59991: [Linux/x86] Fix writing of non-gpr registers on newer processors.

Can we cherry-pick this into a release branch? Skylake (and newer) CPUs are far from rare these days, especially on cloud hosting providers.

Mar 30 2019, 6:11 AM · Restricted Project

Mar 29 2019

davezarzycki committed rG916709e0be44: [CMake] Add missing test dep (authored by davezarzycki).
[CMake] Add missing test dep
Mar 29 2019, 5:00 PM
davezarzycki committed rL357336: [CMake] Add missing test dep.
[CMake] Add missing test dep
Mar 29 2019, 5:00 PM
davezarzycki committed rLLDB357336: [CMake] Add missing test dep.
[CMake] Add missing test dep
Mar 29 2019, 5:00 PM
davezarzycki accepted D59991: [Linux/x86] Fix writing of non-gpr registers on newer processors.

I've verified that this fixes my Skylake-SP (Xeon 8168) workstation. Thanks!

Mar 29 2019, 9:18 AM · Restricted Project

Mar 8 2019

davezarzycki added a comment to D58216: Support attribute used in member funcs of class templates II.

https://bugs.llvm.org/show_bug.cgi?id=41016

Mar 8 2019, 11:02 AM · Restricted Project
davezarzycki added a comment to D58216: Support attribute used in member funcs of class templates II.

I've got a patch pending for Swift. That being said, the clang diagnostics leave something to be desired. If __attribute__((used)) on definitions is sloppy at best or wrong at worst, then that should have a warning/error. Want a bug report? Or does one exist already?

Mar 8 2019, 9:51 AM · Restricted Project

Mar 7 2019

davezarzycki updated subscribers of D58216: Support attribute used in member funcs of class templates II.

I can't get Swift top-of-tree to build with gcc (8.3.1 20190223 (Red Hat 8.3.1-2)), and I doubt that it is supported, but I could be wrong.

Mar 7 2019, 5:57 AM · Restricted Project

Feb 28 2019

davezarzycki added a comment to D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher.

Can we please revert this code? One cannot use dynamic_cast on a char *. Did you mean reinterpret_cast?

Feb 28 2019, 4:03 AM · Restricted Project, Restricted Project

Feb 13 2019

davezarzycki added a comment to D58107: [MinGW] Add the profiling library when necessary.

This change breaks building/testing the compiler with CLANG_DEFAULT_LINKER set to lld. Was this intentional? What should people do if they want to use CLANG_DEFAULT_LINKER and run the test suite?

Feb 13 2019, 4:52 AM · Restricted Project, Restricted Project

Feb 3 2019

davezarzycki added a comment to D57592: Replace uses of %T with %t in from previous frontend test differential .

Hot fix: r352996

Feb 3 2019, 7:51 AM · Restricted Project, Restricted Project
davezarzycki committed rG4a0a64ac1d74: Hot fix two test regressions (%T vs %t) (authored by davezarzycki).
Hot fix two test regressions (%T vs %t)
Feb 3 2019, 7:50 AM
davezarzycki committed rL352996: Hot fix two test regressions (%T vs %t).
Hot fix two test regressions (%T vs %t)
Feb 3 2019, 7:50 AM
davezarzycki committed rC352996: Hot fix two test regressions (%T vs %t).
Hot fix two test regressions (%T vs %t)
Feb 3 2019, 7:50 AM

Jan 31 2019

davezarzycki added a comment to D56928: Support attribute used in member funcs of class templates.

This change broke building Swift on my Linux box. The compiler confusingly complains about the *same* template being both explicitly specialized and implicitly instantiated:

/home/dave/s/u/swift/stdlib/public/runtime/ProtocolConformance.cpp:34:38: error: explicit specialization of 'dump' after instantiation
template <> void ProtocolDescriptor::dump() const {
                                     ^
/home/dave/s/u/swift/stdlib/public/runtime/ProtocolConformance.cpp:34:18: note: implicit instantiation first required here
template <> void ProtocolDescriptor::dump() const {
                 ^

Is this expected?

Jan 31 2019, 5:23 AM · Restricted Project

Dec 21 2018

davezarzycki added a comment to D51798: [Dwarf/AArch64] Return address signing B key dwarf support.

Turns out my setup was busted and I thought I was building/testing AArch64 when I wasn't. I think you need to add // REQUIRES: aarch64-registered-target to the file.

Dec 21 2018, 4:28 AM
davezarzycki added a comment to D51798: [Dwarf/AArch64] Return address signing B key dwarf support.

My mistake. Something else is going on. I assumed based on past precedent that this was what was going on. (I'm not sure how many people at ARM are verifying that their AArch64 commits work when the 32-bit target is disabled).

Dec 21 2018, 4:14 AM
davezarzycki added a comment to D51798: [Dwarf/AArch64] Return address signing B key dwarf support.

FYI – The following test fails if the ARM 32-bit target is NOT built alongside the 64-bit ARM target: MC/ELF/cfi-b-key-frame.s

Dec 21 2018, 3:49 AM

Dec 18 2018

davezarzycki added inline comments to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..
Dec 18 2018, 4:40 AM

Dec 13 2018

davezarzycki added a comment to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..

By the way, LLVM itself will benefit nicely from this change. For example, the code gen for llvm::StringSwitch will improve dramatically.

Dec 13 2018, 3:24 AM

Dec 11 2018

davezarzycki added a comment to D55365: [CodeGen] Allow mempcy/memset to generate small overlapping stores..

This was instantly reverted. Is there a new Differential # I can subscribe to?

Dec 11 2018, 3:29 PM
davezarzycki added a comment to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..

I just looked over the codegen changes so far, but I want to add some more knowledgeable x86 hackers to have a look too. There are 2 concerns:

  1. Are there any known uarch problems with overlapping loads?
  2. Are there any known uarch problems with unaligned accesses (either scalar or SSE)?

    If there's any perf data (either nano-benchmarks or full apps) to support the changes, that would be nice to see. This reminds me of PR33329: https://bugs.llvm.org/show_bug.cgi?id=33329 (can we close that now?)

Let's not lose sight of the big picture here. If uarch problems exist, are they *worse* than the cost of calling memcmp()? In other words, is the likely register spills, function call overhead, and dynamic algorithm selection (given the constantness of the size parameter is lost) worth it?

No real argument from me - I just wanted to be sure that nobody knew of some pre-existing uarch disaster potential. The change should be a nice win for the general x86 case. I've just added some nits in the inline comments.

Dec 11 2018, 3:59 AM

Dec 10 2018

davezarzycki added a comment to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..

I just looked over the codegen changes so far, but I want to add some more knowledgeable x86 hackers to have a look too. There are 2 concerns:

  1. Are there any known uarch problems with overlapping loads?
  2. Are there any known uarch problems with unaligned accesses (either scalar or SSE)?

    If there's any perf data (either nano-benchmarks or full apps) to support the changes, that would be nice to see. This reminds me of PR33329: https://bugs.llvm.org/show_bug.cgi?id=33329 (can we close that now?)
Dec 10 2018, 5:19 AM

Dec 7 2018

davezarzycki added a comment to D55085: Avoid emitting redundant or unusable directories in DIFile metadata entries.

This change broke the test suite when building in /tmp (tmpfs) on Linux:

Dec 7 2018, 7:27 AM · debug-info

Dec 1 2018

davezarzycki added a comment to D54518: [GlobalISel] Fix insertion of stack-protector epilogue.

r347862 of this change broke the ability to run the test suite with the ARM64 backend enabled BUT without the ARM backend enabled. Was this intentional? See below:

Dec 1 2018, 5:05 AM

Oct 12 2018

davezarzycki added a comment to D53219: Update hexagon driver tests.

Tested and verified with -DCLANG_DEFAULT_LINKER=lld

Oct 12 2018, 3:34 PM
davezarzycki accepted D53219: Update hexagon driver tests.
Oct 12 2018, 3:34 PM
davezarzycki added a comment to D53038: [Hexagon] Use GetLinkerPath method instead of hard-coded linker name..

A bisect revealed this change as the source of test failures on my Red Hat Fedora 28 Linux box. How was/is this tested?

Oct 12 2018, 7:26 AM

Jul 18 2018

davezarzycki added a comment to D49457: DR330: when determining whether a cast casts away constness, consider qualifiers from all levels matching a multidimensional array.

Hi @rsmith – I've verified this patch fixes the original issue. Thanks for the quick fix!

Jul 18 2018, 5:10 AM

Jul 12 2018

davezarzycki resigned from D49242: [Intrinsics] define funnel shift IR intrinsics + DAG builder support.
Jul 12 2018, 12:27 PM

Jun 15 2018

davezarzycki removed a reviewer for D47196: [Time-report ](2): Recursive timers in Clang: davezarzycki.
Jun 15 2018, 2:41 PM

May 3 2018

davezarzycki committed rLLD331444: [CMake] Fix BUILD_SHARED_LIBS regression due to r331405.
[CMake] Fix BUILD_SHARED_LIBS regression due to r331405
May 3 2018, 3:08 AM
davezarzycki committed rL331444: [CMake] Fix BUILD_SHARED_LIBS regression due to r331405.
[CMake] Fix BUILD_SHARED_LIBS regression due to r331405
May 3 2018, 3:08 AM

Apr 19 2018

davezarzycki closed D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs.

Committed as r330353

Apr 19 2018, 11:24 AM