After further investigation, it appears that that is not the case and the
actual problem is the additional cases of .replacement being set makes a long
chain of .replacement point to each other, which leads to a long chain of
memref_referenced_p calling each other recursively.
I don't understan
Sent with Proton Mail secure email.
On Wednesday, July 17th, 2024 at 11:20 PM, Jeff Law
wrote:
>
> On 7/15/24 7:53 AM, Vladimir Makarov wrote:
>
> > On 6/14/24 07:10, user202...@protonmail.com wrote:
> >
> > > This patch was inspired from PR 110137. It reduces the amount of stack
> > >
On 7/15/24 7:53 AM, Vladimir Makarov wrote:
On 6/14/24 07:10, user202...@protonmail.com wrote:
This patch was inspired from PR 110137. It reduces the amount of stack
spilling by ensuring that more values are constant across a pure
function call.
It does not add any new flag; rather, it ma
On 6/14/24 07:10, user202...@protonmail.com wrote:
This patch was inspired from PR 110137. It reduces the amount of stack spilling
by ensuring that more values are constant across a pure function call.
It does not add any new flag; rather, it makes the optimizer generate more
optimal code.
This patch was inspired from PR 110137. It reduces the amount of stack spilling
by ensuring that more values are constant across a pure function call.
It does not add any new flag; rather, it makes the optimizer generate more
optimal code.
For the added test file, the change is the following. A
