<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Transforms/Scalar/LoopDataPrefetch.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>[CostModel] Remove optional from InstructionCost::getValue() (#135596)</title>
<updated>2025-04-23T06:46:27+00:00</updated>
<author>
<name>David Green</name>
<email>david.green@arm.com</email>
</author>
<published>2025-04-23T06:46:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=98b6f8dc699d789d834e5b6d810ed217f560aad0'/>
<id>98b6f8dc699d789d834e5b6d810ed217f560aad0</id>
<content type='text'>
InstructionCost is already an optional value, containing an Invalid
state that can be checked with isValid(). There is little point in
returning another optional from getValue(). Most uses do not make use of
it being a std::optional, dereferencing the value directly (either
isValid has been checked previously or the Cost is assumed to be valid).
The one case that does in AMDGPU used value_or which has been replaced
by a isValid() check.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
InstructionCost is already an optional value, containing an Invalid
state that can be checked with isValid(). There is little point in
returning another optional from getValue(). Most uses do not make use of
it being a std::optional, dereferencing the value directly (either
isValid has been checked previously or the Cost is assumed to be valid).
The one case that does in AMDGPU used value_or which has been replaced
by a isValid() check.</pre>
</div>
</content>
</entry>
<entry>
<title>[Scalar] Remove unused includes (NFC) (#114645)</title>
<updated>2024-11-02T15:32:26+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-11-02T15:32:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=94f9cbbe49b4c836cfbed046637cdc0c63a4a083'/>
<id>94f9cbbe49b4c836cfbed046637cdc0c63a4a083</id>
<content type='text'>
Identified with misc-include-cleaner.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with misc-include-cleaner.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLVM] Make more use of IRBuilder::CreateIntrinsic. NFC. (#112706)</title>
<updated>2024-10-17T15:20:43+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2024-10-17T15:20:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=85c17e40926132575d1b98ca1a36b8394fe511cd'/>
<id>85c17e40926132575d1b98ca1a36b8394fe511cd</id>
<content type='text'>
Convert many instances of:
  Fn = Intrinsic::getOrInsertDeclaration(...);
  CreateCall(Fn, ...)
to the equivalent CreateIntrinsic call.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert many instances of:
  Fn = Intrinsic::getOrInsertDeclaration(...);
  CreateCall(Fn, ...)
to the equivalent CreateIntrinsic call.</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)</title>
<updated>2024-10-11T12:26:03+00:00</updated>
<author>
<name>Rahul Joshi</name>
<email>rjoshi@nvidia.com</email>
</author>
<published>2024-10-11T12:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fa789dffb1e12c2aece0187aeacc48dfb1768340'/>
<id>fa789dffb1e12c2aece0187aeacc48dfb1768340</id>
<content type='text'>
Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).</pre>
</div>
</content>
</entry>
<entry>
<title>[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)</title>
<updated>2024-06-27T14:38:15+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-06-27T14:38:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2d209d964a17687f70299d756a7b5e9fa342e0b4'/>
<id>2d209d964a17687f70299d756a7b5e9fa342e0b4</id>
<content type='text'>
This is a helper to avoid writing `getModule()-&gt;getDataLayout()`. I
regularly try to use this method only to remember it doesn't exist...

`getModule()-&gt;getDataLayout()` is also a common (the most common?)
reason why code has to include the Module.h header.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a helper to avoid writing `getModule()-&gt;getDataLayout()`. I
regularly try to use this method only to remember it doesn't exist...

`getModule()-&gt;getDataLayout()` is also a common (the most common?)
reason why code has to include the Module.h header.</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Remove Type::getInt8PtrTy (#71029)</title>
<updated>2023-11-07T16:26:26+00:00</updated>
<author>
<name>Paulo Matos</name>
<email>pmatos@igalia.com</email>
</author>
<published>2023-11-07T16:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7b9d73c2f90c0ed8497339a16fc39785349d9610'/>
<id>7b9d73c2f90c0ed8497339a16fc39785349d9610</id>
<content type='text'>
Replace this with PointerType::getUnqual().
Followup to the opaque pointer transition. Fixes an in-code TODO item.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace this with PointerType::getUnqual().
Followup to the opaque pointer transition. Fixes an in-code TODO item.</pre>
</div>
</content>
</entry>
<entry>
<title>Allow data prefetch into non-default address space</title>
<updated>2022-07-27T17:01:26+00:00</updated>
<author>
<name>Stanislav Mekhanoshin</name>
<email>Stanislav.Mekhanoshin@amd.com</email>
</author>
<published>2022-07-14T19:19:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0562cf442f128e2665ecddc68ca9511a6a4a479b'/>
<id>0562cf442f128e2665ecddc68ca9511a6a4a479b</id>
<content type='text'>
I am playing with the LoopDataPrefetch pass and found out that it
bails to work with a pointer in a non-zero address space. This
patch adds the target callback to check if an address space is to
be considered for prefetching. Default implementation still only
allows address space 0, so this is NFCI.

This does not currently affect any known targets, but seems to be
generally useful for the future.

Differential Revision: https://reviews.llvm.org/D129795
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I am playing with the LoopDataPrefetch pass and found out that it
bails to work with a pointer in a non-zero address space. This
patch adds the target callback to check if an address space is to
be considered for prefetching. Default implementation still only
allows address space 0, so this is NFCI.

This does not currently affect any known targets, but seems to be
generally useful for the future.

Differential Revision: https://reviews.llvm.org/D129795
</pre>
</div>
</content>
</entry>
<entry>
<title>[LoopDataPrefetch] Fix crash when TTI doesn't set CacheLineSize</title>
<updated>2022-07-26T05:08:42+00:00</updated>
<author>
<name>zhongyunde</name>
<email>zhongyunde@huawei.com</email>
</author>
<published>2022-07-26T05:05:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d485c1b73e1331c14c45840a6fcc0133566672b9'/>
<id>d485c1b73e1331c14c45840a6fcc0133566672b9</id>
<content type='text'>
Fix https://github.com/llvm/llvm-project/issues/56681

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D130418
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix https://github.com/llvm/llvm-project/issues/56681

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D130418
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCEVExpander] Make CanonicalMode handing in isSafeToExpand() more robust (PR50506)</title>
<updated>2022-07-14T12:41:51+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2022-07-13T10:18:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dcf4b733ef8e8e876e55b85c0d67c9b32c4fde0e'/>
<id>dcf4b733ef8e8e876e55b85c0d67c9b32c4fde0e</id>
<content type='text'>
isSafeToExpand() for addrecs depends on whether the SCEVExpander
will be used in CanonicalMode. At least one caller currently gets
this wrong, resulting in PR50506.

Fix this by a) making the CanonicalMode argument on the freestanding
functions required and b) adding member functions on SCEVExpander
that automatically take the SCEVExpander mode into account. We can
use the latter variant nearly everywhere, and thus make sure that
there is no chance of CanonicalMode mismatch.

Fixes https://github.com/llvm/llvm-project/issues/50506.

Differential Revision: https://reviews.llvm.org/D129630
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
isSafeToExpand() for addrecs depends on whether the SCEVExpander
will be used in CanonicalMode. At least one caller currently gets
this wrong, resulting in PR50506.

Fix this by a) making the CanonicalMode argument on the freestanding
functions required and b) adding member functions on SCEVExpander
that automatically take the SCEVExpander mode into account. We can
use the latter variant nearly everywhere, and thus make sure that
there is no chance of CanonicalMode mismatch.

Fixes https://github.com/llvm/llvm-project/issues/50506.

Differential Revision: https://reviews.llvm.org/D129630
</pre>
</div>
</content>
</entry>
<entry>
<title>Pipe potentially invalid InstructionCost through CodeMetrics</title>
<updated>2022-06-09T22:17:24+00:00</updated>
<author>
<name>Philip Reames</name>
<email>preames@rivosinc.com</email>
</author>
<published>2022-06-09T22:11:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f85c5079b8d093ed9867733fac2946e3a50ed039'/>
<id>f85c5079b8d093ed9867733fac2946e3a50ed039</id>
<content type='text'>
Per the documentation in Support/InstructionCost.h, the purpose of an invalid cost is so that clients can change behavior on impossible to cost inputs. CodeMetrics was instead asserting that invalid costs never occurred.

On a target with an incomplete cost model - e.g. RISCV - this means that transformations would crash on (falsely) invalid constructs - e.g. scalable vectors. While we certainly should improve the cost model - and I plan to do so in the near future - we also shouldn't be crashing. This violates the explicitly stated purpose of an invalid InstructionCost.

I updated all of the "easy" consumers where bailouts were locally obvious. I plan to follow up with loop unroll in a following change.

Differential Revision: https://reviews.llvm.org/D127131
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per the documentation in Support/InstructionCost.h, the purpose of an invalid cost is so that clients can change behavior on impossible to cost inputs. CodeMetrics was instead asserting that invalid costs never occurred.

On a target with an incomplete cost model - e.g. RISCV - this means that transformations would crash on (falsely) invalid constructs - e.g. scalable vectors. While we certainly should improve the cost model - and I plan to do so in the near future - we also shouldn't be crashing. This violates the explicitly stated purpose of an invalid InstructionCost.

I updated all of the "easy" consumers where bailouts were locally obvious. I plan to follow up with loop unroll in a following change.

Differential Revision: https://reviews.llvm.org/D127131
</pre>
</div>
</content>
</entry>
</feed>
