<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/XRay, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[llvm] Use a new constructor of ArrayRef (NFC) (#146008)</title>
<updated>2025-06-27T06:38:12+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-27T06:38:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=26ec66dc1825824790912aeda85ac998a8374cff'/>
<id>26ec66dc1825824790912aeda85ac998a8374cff</id>
<content type='text'>
ArrayRef now has a new constructor that takes a parameter whose type
has data() and size().  This patch migrates:

  ArrayRef&lt;T&gt;(X.data(), X.size()

to:

  ArrayRef&lt;T&gt;(X)</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ArrayRef now has a new constructor that takes a parameter whose type
has data() and size().  This patch migrates:

  ArrayRef&lt;T&gt;(X.data(), X.size()

to:

  ArrayRef&lt;T&gt;(X)</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Remove unused includes (NFC) (#142733)</title>
<updated>2025-06-04T19:30:52+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-04T19:30:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=228f66807d0be1d7873e075fc81baf41001950b5'/>
<id>228f66807d0be1d7873e075fc81baf41001950b5</id>
<content type='text'>
These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.</pre>
</div>
</content>
</entry>
<entry>
<title>[XRay][RISCV] RISCV support for XRay (#117368)</title>
<updated>2024-12-11T01:57:04+00:00</updated>
<author>
<name>Min-Yih Hsu</name>
<email>min.hsu@sifive.com</email>
</author>
<published>2024-12-11T01:57:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ea76b2d8d83d6885bf5707832cbc4b7655e21b08'/>
<id>ea76b2d8d83d6885bf5707832cbc4b7655e21b08</id>
<content type='text'>
Add RISC-V support for XRay. The RV64 implementation has been tested in
both QEMU and in our hardware environment.

Currently this requires D and C extensions, but since both RV64GC and
RVA22/RVA23 are becoming mainstream, I don't think this requirement will
be a big problem.

Based on the previous work by @a-poduval :
https://reviews.llvm.org/D117929

---------

Co-authored-by: Ashwin Poduval &lt;ashwin.poduval@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add RISC-V support for XRay. The RV64 implementation has been tested in
both QEMU and in our hardware environment.

Currently this requires D and C extensions, but since both RV64GC and
RVA22/RVA23 are becoming mainstream, I don't think this requirement will
be a big problem.

Based on the previous work by @a-poduval :
https://reviews.llvm.org/D117929

---------

Co-authored-by: Ashwin Poduval &lt;ashwin.poduval@gmail.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[XRay] Simplify code with DenseMap::operator[] (NFC) (#111786)</title>
<updated>2024-10-10T15:17:58+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-10-10T15:17:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=35bbfbc7c0d0782bad5160662c9683b38329c7c1'/>
<id>35bbfbc7c0d0782bad5160662c9683b38329c7c1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Use std::make_unique (NFC) (#97165)</title>
<updated>2024-06-29T18:50:41+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-06-29T18:50:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ddaa93b095288ce459be4096193c40a4ea247b11'/>
<id>ddaa93b095288ce459be4096193c40a4ea247b11</id>
<content type='text'>
This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr&lt;Type&gt;(new Type()), which is a bit mouthful.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr&lt;Type&gt;(new Type()), which is a bit mouthful.</pre>
</div>
</content>
</entry>
<entry>
<title>[XRay] Reserve memory space ahead-of-time when reading native format log (#76853)</title>
<updated>2024-01-13T00:34:39+00:00</updated>
<author>
<name>Min-Yih Hsu</name>
<email>min.hsu@sifive.com</email>
</author>
<published>2024-01-13T00:34:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3edf82d5566ed5c9898f52b5591c05f6366d6bac'/>
<id>3edf82d5566ed5c9898f52b5591c05f6366d6bac</id>
<content type='text'>
XRay used to struggle reading large log files. It turned out the
bottleneck was primarily caused by the reallocation happens when
appending log entries into a std::vector.
This patch reserves the memory space ahead-of-time since the number of
entries is known for most cases. Making llvm-xray runs 1.8 times faster
and uses 1.4 times less physical memory when reading large (~2.6GB) log
files.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
XRay used to struggle reading large log files. It turned out the
bottleneck was primarily caused by the reallocation happens when
appending log entries into a std::vector.
This patch reserves the memory space ahead-of-time since the number of
entries is known for most cases. Making llvm-xray runs 1.8 times faster
and uses 1.4 times less physical memory when reading large (~2.6GB) log
files.</pre>
</div>
</content>
</entry>
<entry>
<title>[XRay] Adjust includes of bitset (NFC)</title>
<updated>2023-12-06T04:37:04+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-12-06T04:37:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a2b715920ab6978949db8c85a8afd22942898f5b'/>
<id>a2b715920ab6978949db8c85a8afd22942898f5b</id>
<content type='text'>
BlockVerifier.cpp uses std::bitset, not BlockVerifier.h.

Identified with clangd.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BlockVerifier.cpp uses std::bitset, not BlockVerifier.h.

Identified with clangd.
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Use llvm::endianness::{big,little,native} (NFC)</title>
<updated>2023-10-11T03:14:20+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-10-11T03:14:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b05dbc4d5f28e4fe6ac4486925e09d64861720cc'/>
<id>b05dbc4d5f28e4fe6ac4486925e09d64861720cc</id>
<content type='text'>
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form.  This patch replaces
support::endianness::{big,little,native} with
llvm::endianness::{big,little,native}.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form.  This patch replaces
support::endianness::{big,little,native} with
llvm::endianness::{big,little,native}.
</pre>
</div>
</content>
</entry>
<entry>
<title>[XRay] Add initial support for loongarch64</title>
<updated>2023-07-14T01:27:13+00:00</updated>
<author>
<name>Weining Lu</name>
<email>luweining@loongson.cn</email>
</author>
<published>2023-07-14T01:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ef33d6cbfc2dada0709783563fee57e6afd9a2d9'/>
<id>ef33d6cbfc2dada0709783563fee57e6afd9a2d9</id>
<content type='text'>
Only support patching FunctionEntry/FunctionExit/FunctionTailExit for now.

Reviewed By: MaskRay, xen0n
Co-Authored-By: zhanglimin &lt;zhanglimin@loongson.cn&gt;

Differential Revision: https://reviews.llvm.org/D140727
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only support patching FunctionEntry/FunctionExit/FunctionTailExit for now.

Reviewed By: MaskRay, xen0n
Co-Authored-By: zhanglimin &lt;zhanglimin@loongson.cn&gt;

Differential Revision: https://reviews.llvm.org/D140727
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC][TargetParser] Remove llvm/ADT/Triple.h</title>
<updated>2023-02-07T12:39:46+00:00</updated>
<author>
<name>Archibald Elliott</name>
<email>archibald.elliott@arm.com</email>
</author>
<published>2023-02-07T12:21:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=62c7f035b4392c1933550eead6ddab35122720bc'/>
<id>62c7f035b4392c1933550eead6ddab35122720bc</id>
<content type='text'>
I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.
</pre>
</div>
</content>
</entry>
</feed>
