In D72797#1823452, @djtodoro wrote:

Nice, thanks! Please post the rest of the patches, when you are ready, and make a stack of the patches.

This five patches reduces 'total availability' metric of clang binary
(debug build) from 126% to 87%.

I guess we are talking about the build with -g -O2?

Nice, thanks! Please post the rest of the patches, when you are ready, and make a stack of the patches.

In D71870#1820417, @aprantl wrote:

In D71870#1819207, @djtodoro wrote:

In D71870#1816443, @djtodoro wrote:

@aprantl Thanks for the comment, sorry for the late response, I was on the vacation.

In D71870#1810823, @aprantl wrote:

How ubiquitous is matplotlib? I wonder if it might be better to textually print out a gnuplot file or something similar. OTOH the surface area in the code seems to be really small, so this may be fine.

I see the matplotlib is used within some of the LLVM Python tools, but I can investigate this further in order to see if the gnuplot is better option for this.

@aprantl For this option I would keep using the matplotlib (there is a help message saying we need the library, please see e.g. clang/utils/analyzer/CmpRuns.py).
Although, I think the gnuplot could be useful as well, but I don't see any obstacle that both ways of plotting coexist here, so we can add another feature to the llvm-locstats tool generating a gnuplot text file. WDYT?

Gnuplot also has a weird license and I don't necessarily want to introduce it as a dependency either. But some form of dumping the raw data that is being graphed into some sort of machine-readable output (perhaps CSV?) could be useful for importing it into other tools like spreadsheets, pgfplot, gnuplot and so on.

In D71870#1816443, @djtodoro wrote:

@aprantl Thanks for the comment, sorry for the late response, I was on the vacation.

In D71870#1810823, @aprantl wrote:

How ubiquitous is matplotlib? I wonder if it might be better to textually print out a gnuplot file or something similar. OTOH the surface area in the code seems to be really small, so this may be fine.

I see the matplotlib is used within some of the LLVM Python tools, but I can investigate this further in order to see if the gnuplot is better option for this.

-Addressing comments

-Addressing comments

-Rebase

I guess this should be closed? :)

@aprantl Thanks for the comment, sorry for the late response, I was on the vacation.

@vsk, @dstenb Thank you both for your comments!

Thanks for the comments! Sorry for the late response, I was on the vacation.

Please add a test case.

Thanks for this!

An example of the plot on a GDB binary built with LLVM Trunk using the entry values vs. no entry values.

An example of the plot on a GDB binary built with LLVM Trunk.

Thanks for doing this! Looks good to me now!

Please make sure the tool name is llvm-locstats instead of llvm-covstat.

In D71695#1791081, @djtodoro wrote:

Something like the diff bellow would address the concerns.

diff --git a/llvm/utils/llvm-locstats/CMakeLists.txt b/llvm/utils/llvm-locstats/CMakeLists.txt
index d5366f99050..82099fed314 100644
--- a/llvm/utils/llvm-locstats/CMakeLists.txt
+++ b/llvm/utils/llvm-locstats/CMakeLists.txt
@@ -2,6 +2,7 @@ if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS)
   add_custom_command(
     OUTPUT ${LLVM_TOOLS_BINARY_DIR}/llvm-locstats
     DEPENDS ${LLVM_MAIN_SRC_DIR}/utils/llvm-locstats/llvm-locstats.py
+    DEPENDS llvm-dwarfdump
     COMMAND ${CMAKE_COMMAND} -E copy ${LLVM_MAIN_SRC_DIR}/utils/llvm-locstats/llvm-locstats.py ${LLVM_TOOLS_BINARY_DIR}/llvm-locstats
     COMMENT "Copying llvm-locstats into ${LLVM_TOOLS_BINARY_DIR}"
     )

Something like the diff bellow would address the concerns.

In D71695#1791002, @djtodoro wrote:

In D71695#1790979, @DavidSpickett wrote:

In D71695#1790971, @djtodoro wrote:

Sorry for the confusion. May be the llvm/CMakeLists.txt is better place to address this?

llvm/CMakeLists.txt:

if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS)
  add_subdirectory(utils/llvm-locstats)
endif()

Changing it to:

if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS AND LLVM_BUILD_TOOLS)
  add_subdirectory(utils/llvm-locstats)

Doesn't help the issue, but maybe I'm missing your point here?

Yes that was my point. Should we add the AND LLVM_BUILD_TOOLS part in both of the llvm/CMakeLists.txt and llvm/utils/llvm-locstats/CMakeLists.txt?

This won't solve the problem you reported..

In D71695#1790979, @DavidSpickett wrote:

In D71695#1790971, @djtodoro wrote:

Sorry for the confusion. May be the llvm/CMakeLists.txt is better place to address this?

llvm/CMakeLists.txt:

if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS)
  add_subdirectory(utils/llvm-locstats)
endif()

Changing it to:

if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS AND LLVM_BUILD_TOOLS)
  add_subdirectory(utils/llvm-locstats)

Doesn't help the issue, but maybe I'm missing your point here?

Yes that was my point. Should we add the AND LLVM_BUILD_TOOLS part in both of the llvm/CMakeLists.txt and llvm/utils/llvm-locstats/CMakeLists.txt?

Sorry for the confusion. May be the llvm/CMakeLists.txt is better place to address this?

Hm...actually...this is not good..

Thanks!

Good change! It sound reasonable to me.

Looks good to me! Thanks!

Sorry, one more nit included.

LGTM, thanks!

Thanks for addressing the comments.

Thanks for this! This looks good to me now!

Please address my comments and try using the DIExpression::appendExt(). Thanks.

We can use llvm.org/pr44275 to track improvements for this.

Please wait for someone else from the debug-info project to take a look as well.

This one should be rebased on top of the D71366.

@krisb Thanks for this!

@krisb Thanks for this again. First option seems better to me.

In D71070#1774443, @dblaikie wrote:

In D71070#1774223, @krisb wrote:

@djtodoro , yeah, it doesn't look good.
I also considered an option to rename the first bucket to smth like "No location info" or "Not covered" or something similar then the second can be safely named '0-9%'.
Or simply to use '0-9%' together with '0%' which might be a bit unclear, but as docs say 'The line 0% shows the number and the percentage of DIEs with no location information', it should not be confusing.

does this bucket include 9%? I guess the next bucket starts at 10%, so 0-9 includes 9.99%? so technically this one is (0, 10)% and the next one is [10, 91)% etc... (or I guess you could put the % inside the braces/parens)? but that might be insufficiently obvious to read?

LGTM as well! Thanks!

Hm, the bucket name ‘>0-9%' does not look nice to me as well.

LGTM as well, thanks!

Looks good! Thanks!

Reverted while investigating. I am not sure what happened, since the test passed on my machine. Thanks!

Thanks for the reviews!

LGTM. Thanks for doing this!

I like the way of the implementation. Thanks!

I'm not sure if that's possible here. Everything seems quite interdependent, and the bug fix (functionality change) happens as a result of the structural change (also a functionality change).
I could split this into two or more dependant patches and keep 'related' things together. For example, put all the debug print() updates in a single patch. Not sure that this would this help though, what do you think?
There is a very small change/fix to DbgValueLocation which I included in this patch. I could take that out (and probably should) but it won't have a noticable impact on the diff size.

I see. The semantic of the change does not allow us to get it shorter, so I am OK with that. Thanks for considering that!

@jmorse Thanks for your comment!

Ping.

IMO, if there is no specifications for recognizing the instructions that may zero-extend, the individual per-target handling seems good to me.

LGTM. It might be cleaner to replace the macros with helper functions which accept opcodes as vector<uint64_t> (using brace init on the caller side should be pretty readable).

+1