Page MenuHomePhabricator

cmtice (Caroline Tice)
User

Projects

User Details

User Since
May 3 2018, 11:15 AM (216 w, 6 d)

Recent Activity

Fri, Jun 24

cmtice added a comment to D126864: [clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays.

I did some testing and verified that this commit is causing some of the Sanitizer issues we are seeing. Is there any chance of a revert?

Fri, Jun 24, 4:40 PM · Restricted Project, Restricted Project
cmtice added a comment to D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo.

Just FYI, this commit appears to cause lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py to fail. The error I'm seeing is:

Fri, Jun 24, 12:48 PM · Restricted Project, Restricted Project
cmtice added a comment to D127702: Support logpoints in lldb-vscode.

I apologize; I was looking at several commits, and I accidentally added my comment to the wrong one. No, this commit is not the one that caused my problem (I am very sorry about the confusion).

Fri, Jun 24, 12:47 PM · Restricted Project, Restricted Project
cmtice added a comment to D127702: Support logpoints in lldb-vscode.

Just FYI, this commit appears to cause lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py to fail. The error I'm seeing is:

Fri, Jun 24, 12:29 PM · Restricted Project, Restricted Project

Thu, Jun 23

cmtice added a comment to D126513: Add -b (--continue-to-breakpoint) option to the "process continue" command.

Ignore my revert request; Your later commit seems to have fixed most of my issues.

Thu, Jun 23, 4:17 PM · Restricted Project, Restricted Project
cmtice added a comment to D126513: Add -b (--continue-to-breakpoint) option to the "process continue" command.

This appears to have broken a lot of LLDB tests in our bootstrap as well. Is there any chance this might get reverted?

Thu, Jun 23, 3:58 PM · Restricted Project, Restricted Project

Wed, Jun 22

cmtice added a comment to D124346: [libc++] Complete the implementation of N4190.

@philnik Ah, thanks for pointing that out. Ignore my previous comment. :-)

Wed, Jun 22, 9:45 AM · Restricted Project, Restricted Project
cmtice added a comment to D124346: [libc++] Complete the implementation of N4190.

Just a heads up, this looks like it may have broken compiler-rt builds. I'm seeing errors like:
ERROR: third_party/stl/BUILD:57:11: Compiling third_party/stl/stl.cppmap failed: (Exit 1) wrapped_clang failed: error executing command (from target third_party/stl:stl) third_party/crosstool/v18/llvm_unstable/toolchain/bin/wrapped_clang '-frandom-seed=blaze-out/k8-opt/bin/third_party/stl/_objs/stl/stl.pcm' -iquote . -iquote blaze-out/k8-opt/genfiles -iquote ... (remaining 224 arguments skipped). [forge_remote_host=lmdw19]
While building module '
third_party/stl:stl':
In file included from <module-includes>:43:
./third_party/stl/cxx17/ext/functional:17:24: error: no template named 'unary_function' in namespace 'std'; did you mean '__unary_function'?
struct identity : std::unary_function<T, T> {

~~~~~^~~~~~~~~~~~~~
     __unary_function

third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: 'unary_function' declared here
using
unary_function = unary_function_keep_layout_base<_Arg, _Result>;
^
While building module '//third_party/stl:stl':
In file included from <module-includes>:43:
./third_party/stl/cxx17/ext/functional:22:25: error: no template named 'unary_function' in namespace 'std'; did you mean '
unary_function'?
struct select1st : std::unary_function<Pair, typename Pair::first_type> {

~~~~~^~~~~~~~~~~~~~
     __unary_function

third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: 'unary_function' declared here
using
unary_function = __unary_function_keep_layout_base<_Arg, _Result>;

Wed, Jun 22, 7:34 AM · Restricted Project, Restricted Project

Feb 5 2022

cmtice added a comment to D116637: [Clang][Sema][OpenMP] Sema support for `atomic compare`.

When building/running third_party/llvm/llvm-project/clang/test/OpenMP/atomic_messages.c and third_party/llvm/llvm-project/clang/test/OpenMP/atomic_ast_print.cpp, we get use-of-uninitialized-variable error messages:

Feb 5 2022, 12:11 AM · Restricted Project

Feb 4 2022

cmtice abandoned D119037: Fix target dependencies for libtool in Bazel build files..

Never mind; someone beat me to the fix. Abandoning this.

Feb 4 2022, 2:32 PM
cmtice requested review of D119037: Fix target dependencies for libtool in Bazel build files..
Feb 4 2022, 2:13 PM
cmtice added a comment to D116637: [Clang][Sema][OpenMP] Sema support for `atomic compare`.

This commit is causing some of our builds to fail with these errors:

Feb 4 2022, 10:07 AM · Restricted Project

Feb 3 2022

cmtice added a reviewer for D118955: Update Symbolize dependencies in bazel build file.: GMNGeoffrey.
Feb 3 2022, 4:47 PM
cmtice requested review of D118955: Update Symbolize dependencies in bazel build file..
Feb 3 2022, 4:47 PM

Feb 2 2022

cmtice abandoned D118863: Update mlir bazel build file with appropriate math header dependencies..

It looks like someone else fixed this issue while I was creating this patch: https://github.com/llvm/llvm-project/commit/4a6c9b5686.

Feb 2 2022, 5:00 PM
cmtice requested review of D118863: Update mlir bazel build file with appropriate math header dependencies..
Feb 2 2022, 4:43 PM

Feb 1 2022

cmtice added a comment to D115955: [SLP]Alternate vectorization for cmp instructions..

We're still working on getting you a reproducible test case, but this is definitely causing some bad codegen for us. Could you please revert it while we work on getting you the test case?

Feb 1 2022, 6:12 PM · Restricted Project
cmtice added a comment to D115955: [SLP]Alternate vectorization for cmp instructions..

Just a heads-up: This commit appears to be breaking some of our tests. We're working on trying to get a reproducible test case.

Feb 1 2022, 5:25 PM · Restricted Project

Jan 31 2022

cmtice added a comment to D116542: [OpenMP] Add a flag for embedding a file into the module.

This change introduces a circular dependency: BitcodeWriters now depends on TransformUtils, but TransformUtils also depends on BitcodeWriters. This appears to be a layering violation.

Jan 31 2022, 3:35 PM · Restricted Project, Restricted Project

Aug 12 2021

cmtice added a comment to rG6de1dbbd09c1: [InstCombine] factorize min/max intrinsic ops with common operand.

Just a heads up: We are seeing some new clang/llvm crashes, and we believe this CL is the culprit. I am working on trying to get a good reproducer. This CL may need to be reverted.

Aug 12 2021, 12:21 PM

Jun 30 2021

cmtice committed rG05915400b7f9: [lldb] Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with… (authored by cmtice).
[lldb] Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with…
Jun 30 2021, 9:27 AM
cmtice closed D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.
Jun 30 2021, 9:27 AM · Restricted Project

Jun 26 2021

cmtice added a comment to D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.

I have tried to build lldb-server for aarch64 inside Chrome OS following the instructions above, but due to the way things build in Chrome OS (using the Gentoo Linux portage system) this does not work. I also have not been able to find these definitions in ptrace.h files inside Chrome OS.

Jun 26 2021, 10:54 PM · Restricted Project

Jun 23 2021

cmtice added a comment to D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.

Can we do this just using clang/llvm? We've stopped using GCC in Chrome OS and have pretty much removed it altogether.

Jun 23 2021, 5:15 PM · Restricted Project
cmtice added a comment to D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.

To be clear, this is all elf/linux, and the builds happen on x86_64 machines.

Jun 23 2021, 5:04 PM · Restricted Project
cmtice added a comment to D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.

I found a need for this change when I was trying to build (cross-compile) lldb/lldb-server for aarch64 inside Chrome OS -- the build I had was failing for aarch64 with all of these symbols "undefined". If you can tell me the cmake configs and/or build flags I should use to try to get these symbols from ptrace.h, I can try that instead. But since this is a cross-compile, they might not be available on the build system?

Jun 23 2021, 5:02 PM · Restricted Project
cmtice retitled D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h from Replace SVE_PT* in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h to Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.
Jun 23 2021, 4:52 PM · Restricted Project
cmtice added reviewers for D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h: labath, omjavaid.
Jun 23 2021, 4:49 PM · Restricted Project
cmtice requested review of D104826: Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h.
Jun 23 2021, 4:47 PM · Restricted Project

Apr 16 2021

cmtice committed rG3dc24bc31edb: [LLDB] Re-land: Use path relative to binary for finding .dwo files. (authored by cmtice).
[LLDB] Re-land: Use path relative to binary for finding .dwo files.
Apr 16 2021, 11:13 AM
cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Pavel's test case passed on my local machine (x86_64 linux workstation).

Apr 16 2021, 8:00 AM · Restricted Project, Restricted Project, Restricted Project
cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Hi Pavel,

Apr 16 2021, 7:20 AM · Restricted Project, Restricted Project, Restricted Project

Apr 15 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I had to revert this change because the test case broke the windows builder. What's the right way to update/mark the test case so that it is only run on appropriate architectures & operating systems?

Apr 15 2021, 5:23 PM · Restricted Project, Restricted Project, Restricted Project
cmtice added a reverting change for rGb241f3cb292d: [LLDB] Use path relative to binary for finding .dwo files.: rG042668d092bb: Revert "[LLDB] Use path relative to binary for finding .dwo files.".
Apr 15 2021, 5:19 PM
cmtice committed rG042668d092bb: Revert "[LLDB] Use path relative to binary for finding .dwo files." (authored by cmtice).
Revert "[LLDB] Use path relative to binary for finding .dwo files."
Apr 15 2021, 5:19 PM
cmtice added a reverting change for D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.: rG042668d092bb: Revert "[LLDB] Use path relative to binary for finding .dwo files.".
Apr 15 2021, 5:19 PM · Restricted Project, Restricted Project, Restricted Project
cmtice committed rGb241f3cb292d: [LLDB] Use path relative to binary for finding .dwo files. (authored by cmtice).
[LLDB] Use path relative to binary for finding .dwo files.
Apr 15 2021, 2:44 PM
cmtice closed D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..
Apr 15 2021, 2:44 PM · Restricted Project, Restricted Project, Restricted Project

Apr 14 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I did leave 'main' in the .s file, but it's not very big. Is this ok now?

Apr 14 2021, 9:02 PM · Restricted Project, Restricted Project, Restricted Project
cmtice updated the diff for D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Update test case to use lldb on .o file and not run the inferior.

Apr 14 2021, 9:01 PM · Restricted Project, Restricted Project, Restricted Project

Apr 13 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Pavel, your last comment lost me completely. How can I test the code I added to lldb if I don't run lldb? I am a complete newbie at writing test cases so there's probably something basic I'm missing? How would I observe the value of the variable without running lldb? Also, if the program doesn't contain 'main', won't the compiler complain? Is there an existing test that does what you're suggesting that I could look at?

Apr 13 2021, 7:40 AM · Restricted Project, Restricted Project, Restricted Project

Apr 8 2021

cmtice updated the diff for D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Add a test case.

Apr 8 2021, 5:15 PM · Restricted Project, Restricted Project, Restricted Project

Apr 7 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

It has taken a bit of time to get through the GDB reviews, but the change to GDB was accepted and committed: https://sourceware.org/pipermail/gdb-cvs/2021-April/050267.html

Apr 7 2021, 9:09 AM · Restricted Project, Restricted Project, Restricted Project

Mar 7 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I'm not sure about using target.debug-file-search-paths, and what the changes Pavel is suggesting would entail.

I imagine it would involve calling Symbols::LocateExecutableSymbolFile to locate the dwo file, similar to how we do that for dwp files (see SymbolFileDWARF::GetDwpSymbolFile). (Disclaimer: I have not tried doing this, so I don't know if that function would work out-of-the-box.)
Note that I myself am not convinced that this is the right solution (that function is rather heavy), but it does solve the problem of "how do we let the user specify/choose the location of the dwo files" (answer: put the path in the target.debug-file-search-paths setting), and it would search the cwd and the module directory automatically. And the "heavy-ness" of the function is moderated by the fact that it is a no-op for absolute paths to existing files.

But the real question I am trying to resolve here is not "what are all the places we should be searching for the .dwo files?" but "When we're given a *relative path* in the DWARF for finding the files, what should it be relative TO?".

I'm sorry, but what's the difference between those two questions? Is it about the fact that the second question sort of implies that there should only be one correct location where we should be searching?

Mar 7 2021, 8:53 AM · Restricted Project, Restricted Project, Restricted Project

Mar 4 2021

cmtice updated the diff for D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Update to incorporate Pavel's suggested simplification.

Mar 4 2021, 8:46 AM · Restricted Project, Restricted Project, Restricted Project
cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I'm not sure about using target.debug-file-search-paths, and what the changes Pavel is suggesting would entail. But the real question I am trying to resolve here is not "what are all the places we should be searching for the .dwo files?" but "When we're given a *relative path* in the DWARF for finding the files, what should it be relative TO?".

Mar 4 2021, 8:01 AM · Restricted Project, Restricted Project, Restricted Project

Mar 2 2021

cmtice added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

It is true that the compiler will not know where the final executable will be placed, and if the executable gets moved then debugging with .dwo files will probably not work anyway, However as it is currently written, LLDB will fail to find the .dwo files, *even when the binary has not been moved*, if the debugger is launched from any directory other than the one containing the binary.

Mar 2 2021, 11:28 AM · Restricted Project, Restricted Project, Restricted Project
cmtice updated the diff for D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Upload the correct patch this time. (sorry!)

Mar 2 2021, 11:04 AM · Restricted Project, Restricted Project, Restricted Project
cmtice updated subscribers of D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Something went very wrong on the patch upload. This does NOT look like the
patch I intended!

Mar 2 2021, 10:55 AM · Restricted Project, Restricted Project, Restricted Project
cmtice requested review of D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..
Mar 2 2021, 10:50 AM · Restricted Project, Restricted Project, Restricted Project

Apr 23 2020

cmtice added a member for debug-info: cmtice.
Apr 23 2020, 2:40 PM

Nov 7 2019

cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Fix small typo in comments.

Nov 7 2019, 8:00 AM · Restricted Project

Nov 6 2019

cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Remove quotes from -NOT tests.

Nov 6 2019, 2:20 PM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Fix NODEBUGINFO-NOT test.

Nov 6 2019, 1:24 PM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Remove period from help text. Fix tests.

Nov 6 2019, 12:02 PM · Restricted Project

Nov 5 2019

cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Rename flag to -fdebug-default-version; add help text, mentioning DWARF. Update tests to use -### and add assembler tests.

Nov 5 2019, 3:51 PM · Restricted Project
cmtice added a comment to D69822: [clang] Add new -fdebug-default-version flag..

Yes, I will change the flag name back to debug-default-version, and add help text mentioning dwarf. I'm in the process of trying to re-do the test cases as required (I'm a bit new to this so it's taking me a bit to figure this out).

Nov 5 2019, 2:29 PM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Make second call to ParseDwarfDefaultVersion unconditional (to match the first and avoid errors with -Werror).

Nov 5 2019, 1:06 PM · Restricted Project
cmtice added a comment to D69822: [clang] Add new -fdebug-default-version flag..

For the record, I double-checked and if we use the flag and don't check for it (i.e. if we move the parsing inside the EmitDwarf is True block) then -Werror does indeed complain about an unused command line argument.

Nov 5 2019, 12:57 PM · Restricted Project
cmtice added a comment to D69822: [clang] Add new -fdebug-default-version flag..

dblaikie: The code, as written, parses the dwarf default version flag, whether or not DWARFVersion is 0, i.e. whether or not a -gdwarf-N flag was passed. It only USES the value if there's no overriding value.

Nov 5 2019, 12:29 PM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

re-try upload again.

Nov 5 2019, 11:52 AM · Restricted Project
cmtice added a comment to D69822: [clang] Add new -fdebug-default-version flag..

Ok, I think the upload was correct this time.

Nov 5 2019, 11:52 AM · Restricted Project
cmtice added a comment to D69822: [clang] Add new -fdebug-default-version flag..

Hmmm...I'm having upload issues.

Nov 5 2019, 11:52 AM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Try uploading correct diff file?

Nov 5 2019, 11:52 AM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Made requested changes:

  • renamed option to be dwarf-specific
  • fixed spelling & blank line issues
  • only set version if emit-dwarf is true
  • move test to Driver directory
Nov 5 2019, 10:10 AM · Restricted Project

Nov 4 2019

cmtice updated the summary of D69822: [clang] Add new -fdebug-default-version flag..
Nov 4 2019, 3:21 PM · Restricted Project
cmtice updated the diff for D69822: [clang] Add new -fdebug-default-version flag..

Made requested formatting changes.

Nov 4 2019, 1:58 PM · Restricted Project
cmtice added inline comments to D69822: [clang] Add new -fdebug-default-version flag..
Nov 4 2019, 1:40 PM · Restricted Project
cmtice created D69822: [clang] Add new -fdebug-default-version flag..
Nov 4 2019, 1:19 PM · Restricted Project

Jun 5 2019

cmtice added a comment to D54348: Permit multiple .file directives with -g.

Ping? Is anybody looking at or working on this? The bug this fixes is one of the issues currently blocking Chrome OS from being able to adopt Dwarf v5, so we are hoping for a fix?

Hmm, apologies. I will take a look tomorrow to try and pick this back up. But unfortunately I'll be away on vacation after tomorrow and it may not be addressed soon. Is Dwarfv5 for ChromeOS bound to a particular llvm release or release date?

Jun 5 2019, 4:45 PM · Restricted Project, debug-info
Herald added a project to D54348: Permit multiple .file directives with -g: Restricted Project.

Ping? Is anybody looking at or working on this? The bug this fixes is one of the issues currently blocking Chrome OS from being able to adopt Dwarf v5, so we are hoping for a fix?

Jun 5 2019, 4:06 PM · Restricted Project, debug-info

May 13 2019

cmtice closed D61755: llvm-dwarfdump: Add dwo parsing to --statistics..

Committed in r360380.

May 13 2019, 10:08 AM · Restricted Project

May 9 2019

cmtice committed rGabf25745b339: llvm-dwarfdump: Add dwo parsing to --statistics. (authored by cmtice).
llvm-dwarfdump: Add dwo parsing to --statistics.
May 9 2019, 2:52 PM
cmtice created D61755: llvm-dwarfdump: Add dwo parsing to --statistics..
May 9 2019, 1:13 PM · Restricted Project

Apr 1 2019

cmtice committed rG2a67c910764b: Commit accidentally omitted test case. (authored by cmtice).
Commit accidentally omitted test case.
Apr 1 2019, 9:30 AM
cmtice added a comment to D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

Test case has been committed, as of revision 357409.

Apr 1 2019, 9:30 AM · Restricted Project

Mar 1 2019

cmtice committed rGbcdb1f3d04ae: llvm-dwarfdump: Add new variable, parameter and inlining statistics; also… (authored by cmtice).
llvm-dwarfdump: Add new variable, parameter and inlining statistics; also…
Mar 1 2019, 3:51 PM
cmtice updated the diff for D58849: llvm-dwarfdump: Add new variable, parameter and inlining statistics; also function source location statistics..

Ran clang-format on Statistics.cpp

Mar 1 2019, 3:09 PM · Restricted Project
cmtice created D58849: llvm-dwarfdump: Add new variable, parameter and inlining statistics; also function source location statistics..
Mar 1 2019, 2:13 PM · Restricted Project

Feb 7 2019

cmtice committed rGcef4c294170d: lvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions"… (authored by cmtice).
lvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions"…
Feb 7 2019, 4:52 PM
cmtice added a comment to D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..

It appears to me that on line 131 we are already adding/counting the ConstantMembers in FnStats.VarsInFunction, so adding "+ Constants" would be counting them twice. Alternatively we can change the code on line 131 to not include ConstantMembers...

Feb 7 2019, 4:33 PM · Restricted Project
cmtice updated the diff for D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..

I was mistaken before: we were never counting the template parameters. What was happening was that we were counting the variables in both inlined instances, and we were also counting the variables for a concrete, out-of-line instance of the inlined function, even though in this particular case there was no concrete out-of-line instance. I have updated the patch now to only count vars in DW_TAG_subprogram DIEs if the subprogram DIE has PC addresses. I believe this is the correct fix for this issue.

Feb 7 2019, 4:10 PM · Restricted Project
cmtice updated the diff for D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..

This increases the version number, as requested.

Feb 7 2019, 11:02 AM · Restricted Project
cmtice added inline comments to D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..
Feb 7 2019, 10:56 AM · Restricted Project
cmtice updated the diff for D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..

Now we correctly count only real constant members as "constant members" and we count global variables with locations as part of the "vars with locs".

Feb 7 2019, 10:07 AM · Restricted Project
cmtice updated the diff for D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..

aprantl@, you were right, my original change was not correctly updating the variable counts to include variables occuring in inlined instances of functions. I have update the patch to fix this issue. There were two additional changes needed: one to make sure we were counting variables for functions that had no inlined instances at all; and one to avoid double-counting member constants.

Feb 7 2019, 9:08 AM · Restricted Project

Feb 6 2019

cmtice created D57849: llvm-dwarfdump: Stop counting out-of-line subprogram in the "inlined functions" statistic..
Feb 6 2019, 2:41 PM · Restricted Project

Sep 21 2018

cmtice created D52383: Fix codemodels.c test case (only test mcmodel-kernel on x86).
Sep 21 2018, 4:03 PM
cmtice updated the diff for D52322: Pass code-model through Module IR to LTO which will use is.

Use Conf.CodeModel in LTO, if it exists.

Sep 21 2018, 10:37 AM
cmtice updated the diff for D52322: Pass code-model through Module IR to LTO which will use is.

Add comment explaining why mixing two code models is an error. Add missing Inputs/codemodel-3.ll file.

Sep 21 2018, 9:46 AM
cmtice updated the diff for D52323: Add necessary support for storing code-model to module IR..

Move include statement from CodeGenModule.h to CodeGenModule.cpp
Remove incorrect "default" case statement.
Add test for "tiny" code model.

Sep 21 2018, 9:39 AM
cmtice added inline comments to D52323: Add necessary support for storing code-model to module IR..
Sep 21 2018, 9:33 AM

Sep 20 2018

cmtice updated the summary of D52322: Pass code-model through Module IR to LTO which will use is.
Sep 20 2018, 2:20 PM
cmtice created D52323: Add necessary support for storing code-model to module IR..
Sep 20 2018, 2:19 PM
cmtice created D52322: Pass code-model through Module IR to LTO which will use is.
Sep 20 2018, 2:15 PM

Jul 20 2018

cmtice updated the diff for D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

Simplify test case, as requested by Peter.

Jul 20 2018, 4:34 PM · Restricted Project
cmtice updated the diff for D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

I just realized that my patch did not contain the actual move of RuntimeLibcalls.def from CodeGen to IR. This update includes that move.

Jul 20 2018, 2:35 PM · Restricted Project
cmtice updated the diff for D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

Made requested fixes.

Jul 20 2018, 11:25 AM · Restricted Project
cmtice updated the diff for D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

I've made Peter's suggested changes.

Jul 20 2018, 8:36 AM · Restricted Project

Jul 19 2018

cmtice updated the diff for D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

pcc's original suggested fix did not work, because the real issue was the function definitions being initially internalized by LTO and later DCE'd. Peter's suggestion did not prevent them from being internalized. I consulted with him offline and we came up with this alternative solution. It fixes the issue for the new LTO implemention. The old LTO implementation still internalizes the function definitions, but they do not get Dead Code Eliminated. I have also fixed the test case, and have generalized the code to check for all builtin functions (as requested).

Jul 19 2018, 2:51 PM · Restricted Project