[llvm-branch-commits] [llvm] 776bb71 - [XCore][docs] Fix XCore compiler writer documentation links.

[J. Ryan Stinnett via llvm-branch-commits]

Author: Nigel Perks
Date: 2020-12-08T12:21:09Z
New Revision: 776bb71d88e48a77fc6788324d30bbc63581d6a9

URL: 
https://github.com/llvm/llvm-project/commit/776bb71d88e48a77fc6788324d30bbc63581d6a9
DIFF: 
https://github.com/llvm/llvm-project/commit/776bb71d88e48a77fc6788324d30bbc63581d6a9.diff

LOG: [XCore][docs] Fix XCore compiler writer documentation links.

Fix links to XMOS website. Add link for XS2 architecture.

Reviewed By: jryans

Differential Revision: https://reviews.llvm.org/D92019

Added: 


Modified: 
llvm/docs/CompilerWriterInfo.rst

Removed: 




diff  --git a/llvm/docs/CompilerWriterInfo.rst 
b/llvm/docs/CompilerWriterInfo.rst
index 55c2b92e4931..9184b852539d 100644
--- a/llvm/docs/CompilerWriterInfo.rst
+++ b/llvm/docs/CompilerWriterInfo.rst
@@ -131,8 +131,9 @@ X86
 XCore
 -
 
-* `The XMOS XS1 Architecture (ISA) 
`_
-* `Tools Development Guide (includes ABI) 
`_
+* `The XMOS XS1 Architecture (ISA) 
`_
+* `The XMOS XS2 Architecture (ISA) 
`_
+* `Tools Development Guide (includes ABI) 
`_
 
 Hexagon
 ---



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [DLCov] Origin-Tracking: Enable collecting and symbolizing stack traces (PR #143591)

[J. Ryan Stinnett via llvm-branch-commits]

jryans wrote:

> This patch adds a pair of new functions in `signals.h` that can be used to 
> collect and symbolize stack traces respectively. This has major 
> implementation overlap with the existing stack trace collection/symbolizing 
> methods, but the existing functions are specialized for dumping a stack trace 
> to stderr when LLVM crashes, while these new functions are meant to be called 
> repeatedly during the execution of the program, and therefore we need a 
> separate set of functions.

This is the main point I was questioning last time, and I am still not sure I 
follow your thinking here. There's quite a lot of duplicated code, and I 
believe it would be best for future maintenance if we could reduce that 
duplication as much as possible.

It looks like your new function builds up some data in memory, rather than 
writing it all to output. Perhaps `printSymbolizedStackTrace` could be 
reimplemented to call your new `symbolizeAddresses`, thus reducing duplication 
significantly?

Perhaps I've missed some crucial reason why that's hard to do here...? 

I definitely want to see this work move forward in some form. I'm just trying 
to reduce future maintenance work where possible.

> NB: These functions are only present when origin-tracking is enabled in 
> CMake. Carrying over a conversation from when this was last put up for 
> review, where @jryans requested that the functions be made available 
> unconditionally, I personally believe that since the functions are doing 
> "unusual" things it would be better to avoid compiling them in until we have 
> a confirmed second use-case; I could easily be swayed from this if there's a 
> good argument that another category of users exists, or that in principle 
> there's not a good reason to hide the functions.

Making the new function available unconditionally is less important to me than 
reducing the code duplication discussed above. It still do believe other users 
will likely emerge (as I can imagine wanting to use this for some of my own 
projects), but if you'd rather hide it for now, that's okay with me. (A second 
use case can be the one to remove the compile guards, for example.)

https://github.com/llvm/llvm-project/pull/143591
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits