<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/unittests/Analysis/TargetLibraryInfoTest.cpp, branch main</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>[Analysis] Move TargetLibraryInfo data to TableGen (#165009)</title>
<updated>2025-11-19T21:05:00+00:00</updated>
<author>
<name>Kai Nacke</name>
<email>kai.peter.nacke@ibm.com</email>
</author>
<published>2025-11-19T21:05:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c9f573463ebd7b4e46da4877802f2364f700e54a'/>
<id>c9f573463ebd7b4e46da4877802f2364f700e54a</id>
<content type='text'>
The collection of library function names in TargetLibraryInfo faces
similar challenges as RuntimeLibCalls in the IR component. The number of
function names is large, there are numerous customizations based on the
triple (including alternate names), and there is a lot of replicated
data in the signature table.

The ultimate goal would be to capture all lbrary function related
information in a .td file. This PR brings the current .def file to
TableGen, almost as a 1:1 replacement. However, there are some
improvements which are not possible in the current implementation:

- the function names are now stored as a long string together with an
offset table.
- the table of signatures is now deduplicated, using an offset table for
access.

The size of the object file decreases about 34kB with these changes. The
hash table of all function names is still constructed dynamically. A
static table like for RuntimeLibCalls is the next logical step.

The main motivation for this change is that I have to add a large number
of custom names for z/OS (like in RuntimeLibCalls.td), and the current
infrastructur does not support this very well.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The collection of library function names in TargetLibraryInfo faces
similar challenges as RuntimeLibCalls in the IR component. The number of
function names is large, there are numerous customizations based on the
triple (including alternate names), and there is a lot of replicated
data in the signature table.

The ultimate goal would be to capture all lbrary function related
information in a .td file. This PR brings the current .def file to
TableGen, almost as a 1:1 replacement. However, there are some
improvements which are not possible in the current implementation:

- the function names are now stored as a long string together with an
offset table.
- the table of signatures is now deduplicated, using an offset table for
access.

The size of the object file decreases about 34kB with these changes. The
hash table of all function names is still constructed dynamically. A
static table like for RuntimeLibCalls is the next logical step.

The main motivation for this change is that I have to add a large number
of custom names for z/OS (like in RuntimeLibCalls.td), and the current
infrastructur does not support this very well.</pre>
</div>
</content>
</entry>
<entry>
<title>[TLI] Add basic support for nextafter/nexttoward libcalls (#166250)</title>
<updated>2025-11-05T21:18:18+00:00</updated>
<author>
<name>Sayan Sivakumaran</name>
<email>sivakusayan@gmail.com</email>
</author>
<published>2025-11-05T21:18:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e79528f7b82b6dc98bc8a81d202d58aef3f26519'/>
<id>e79528f7b82b6dc98bc8a81d202d58aef3f26519</id>
<content type='text'>
First patch for #74368. Constant folding will be added in a follow-up
patch.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
First patch for #74368. Constant folding will be added in a follow-up
patch.</pre>
</div>
</content>
</entry>
<entry>
<title>TargetLibraryInfo: Delete default TargetLibraryInfoImpl constructor (#145826)</title>
<updated>2025-06-26T07:12:36+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2025-06-26T07:12:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c91cbafad2119cace85499e8d231b8e5737f3b41'/>
<id>c91cbafad2119cace85499e8d231b8e5737f3b41</id>
<content type='text'>
It should not be possible to construct one without a triple. It would
also be nice to delete TargetLibraryInfoWrapperPass, but that is more
difficult.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It should not be possible to construct one without a triple. It would
also be nice to delete TargetLibraryInfoWrapperPass, but that is more
difficult.</pre>
</div>
</content>
</entry>
<entry>
<title>[TLI] Add support for pvalloc() (#144949)</title>
<updated>2025-06-23T10:03:35+00:00</updated>
<author>
<name>Marco Elver</name>
<email>elver@google.com</email>
</author>
<published>2025-06-23T10:03:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0662045bdf6ca2186511dd84f3b2248bedece690'/>
<id>0662045bdf6ca2186511dd84f3b2248bedece690</id>
<content type='text'>
While pvalloc() is a legacy POSIX function, it remains widely available
in common C libraries like glibc.

Model pvalloc() in TargetLibraryInfo, allowing LLVM to correctly infer
its attributes.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While pvalloc() is a legacy POSIX function, it remains widely available
in common C libraries like glibc.

Model pvalloc() in TargetLibraryInfo, allowing LLVM to correctly infer
its attributes.</pre>
</div>
</content>
</entry>
<entry>
<title>[TLI] Add support for reallocarray (#114818)</title>
<updated>2024-11-13T20:57:29+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@mozilla.com</email>
</author>
<published>2024-11-13T20:57:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dc4185fe2f9635791c6bab04ace29e090949a18e'/>
<id>dc4185fe2f9635791c6bab04ace29e090949a18e</id>
<content type='text'>
reallocarray is available in glibc since 2.29 under _DEFAULT_SOURCE and
under _GNU_SOURCE before, let's model it appropriately.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
reallocarray is available in glibc since 2.29 under _DEFAULT_SOURCE and
under _GNU_SOURCE before, let's model it appropriately.</pre>
</div>
</content>
</entry>
<entry>
<title>[IR] Disallow recursive types (#114799)</title>
<updated>2024-11-05T09:41:10+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2024-11-05T09:41:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4831e0aa88debb3b7d0528bfd85db73a6a03aeff'/>
<id>4831e0aa88debb3b7d0528bfd85db73a6a03aeff</id>
<content type='text'>
StructType::setBody is the only mechanism that can potentially create
recursion in the type system. Add a runtime check that it is not
actually used to create recursion.

If the check fails, report an error from LLParser, BitcodeReader and
IRLinker. In all other cases assert that the check succeeds.

In future StructType::setBody will be removed in favor of specifying the
body when the type is created, so any performance hit from this runtime
check will be temporary.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
StructType::setBody is the only mechanism that can potentially create
recursion in the type system. Add a runtime check that it is not
actually used to create recursion.

If the check fails, report an error from LLParser, BitcodeReader and
IRLinker. In all other cases assert that the check succeeds.

In future StructType::setBody will be removed in favor of specifying the
body when the type is created, so any performance hit from this runtime
check will be temporary.</pre>
</div>
</content>
</entry>
<entry>
<title>[Reland][TLI] Add support for hypot libcall. (#114343)</title>
<updated>2024-10-31T14:50:29+00:00</updated>
<author>
<name>Kenji Mouri / 毛利 研二</name>
<email>Kenji.Mouri@outlook.com</email>
</author>
<published>2024-10-31T14:50:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7e877fc0ac3492a195f2ca587837db79e3729fcc'/>
<id>7e877fc0ac3492a195f2ca587837db79e3729fcc</id>
<content type='text'>
This patch adds basic support for `hypot`. Constant folding support will
be submitted in a subsequent patch.

Related issue: https://github.com/llvm/llvm-project/issues/113711

Note: It's my first time contributing to the LLVM with encouragement
from one of my friends, @fawdlstty. I learned a lot from
https://github.com/llvm/llvm-project/pull/99611, and thanks for that.

Note: I had created the same PR and merged
(https://github.com/llvm/llvm-project/pull/113724), but reverted caused
by the merging issue. (The CI issue happened in 3 A.M. at my timezone.
So, I need to fall asleep again after I replied about why issue
happened.) So, I rebased to the latest main branch and recreate the PR
and hope I won't have the third time to create the same PR.

I hope @arsenm can help me review the code again. I’m sorry for that.

Kenji Mouri</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds basic support for `hypot`. Constant folding support will
be submitted in a subsequent patch.

Related issue: https://github.com/llvm/llvm-project/issues/113711

Note: It's my first time contributing to the LLVM with encouragement
from one of my friends, @fawdlstty. I learned a lot from
https://github.com/llvm/llvm-project/pull/99611, and thanks for that.

Note: I had created the same PR and merged
(https://github.com/llvm/llvm-project/pull/113724), but reverted caused
by the merging issue. (The CI issue happened in 3 A.M. at my timezone.
So, I need to fall asleep again after I replied about why issue
happened.) So, I rebased to the latest main branch and recreate the PR
and hope I won't have the third time to create the same PR.

I hope @arsenm can help me review the code again. I’m sorry for that.

Kenji Mouri</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[TLI] Add support for hypot libcall." (#114312)</title>
<updated>2024-10-30T22:10:29+00:00</updated>
<author>
<name>gulfemsavrun</name>
<email>gulfem@google.com</email>
</author>
<published>2024-10-30T22:10:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=36d56925706a32a065ec50d5a6b418e1f29a27b3'/>
<id>36d56925706a32a065ec50d5a6b418e1f29a27b3</id>
<content type='text'>
Reverts llvm/llvm-project#113724</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#113724</pre>
</div>
</content>
</entry>
<entry>
<title>[TLI] Add support for hypot libcall. (#113724)</title>
<updated>2024-10-30T17:34:32+00:00</updated>
<author>
<name>Kenji Mouri / 毛利 研二</name>
<email>Mouri_Naruto@Outlook.com</email>
</author>
<published>2024-10-30T17:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=feb2d867fac3b6339c169fff97ddf0716fce6f0a'/>
<id>feb2d867fac3b6339c169fff97ddf0716fce6f0a</id>
<content type='text'>
This patch adds basic support for `hypot`. Constant folding support will
be submitted in a subsequent patch.

Related issue: https://github.com/llvm/llvm-project/issues/113711

Note: It's my first time contributing to the LLVM with encouragement
from one of my friends, @fawdlstty. I learned a lot from
https://github.com/llvm/llvm-project/pull/99611, and thanks for that.

Kenji Mouri</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds basic support for `hypot`. Constant folding support will
be submitted in a subsequent patch.

Related issue: https://github.com/llvm/llvm-project/issues/113711

Note: It's my first time contributing to the LLVM with encouragement
from one of my friends, @fawdlstty. I learned a lot from
https://github.com/llvm/llvm-project/pull/99611, and thanks for that.

Kenji Mouri</pre>
</div>
</content>
</entry>
<entry>
<title>[TLI] Add support for the `tgamma` libcall. (#113791)</title>
<updated>2024-10-29T02:08:38+00:00</updated>
<author>
<name>c8ef</name>
<email>c8ef@outlook.com</email>
</author>
<published>2024-10-29T02:08:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0c1c37bfbed08c9d4e414a10f46cbed9a3e4c870'/>
<id>0c1c37bfbed08c9d4e414a10f46cbed9a3e4c870</id>
<content type='text'>
This patch adds the `tgamma` libcall.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds the `tgamma` libcall.</pre>
</div>
</content>
</entry>
</feed>
