o use
CONST_INT_P rather than checking the code directory and pushed the final
version to the trunk.
Thanks for your patience.
jeff
commit a16dc729fda9fabd6472d50cce45791cb3b6ada8
Author: Jivan Hakobyan
Date: Wed Aug 9 13:26:58 2023 -0600
RISC-V: Folding memory for FP + constant cas
Hi Jeff,
Thanks for all the info!
Then I'll prepare/test a patch that removes this regcprop limitation
and send it out.
I have already tested that this change is enough to make fmo optimize
leela as well.
Manolis
On Fri, Aug 4, 2023 at 7:23 PM Jeff Law wrote:
>
>
>
> On 8/4/23 03:52, Manolis
On 8/4/23 03:52, Manolis Tsamis wrote:
Hi all,
It is true that regcprop currently does not propagate sp and hence
leela is not optimized, but from what I see this should be something
we can address.
The reason that the propagation fails is this check that I have added
when I introduced
Hi all,
It is true that regcprop currently does not propagate sp and hence
leela is not optimized, but from what I see this should be something
we can address.
The reason that the propagation fails is this check that I have added
when I introduced maybe_copy_reg_attrs:
else if (REG_POINTER
On 8/1/23 17:38, Vineet Gupta wrote:
Also note that getting FP out of the shift-add sequences is the other
key goal of Jivan's work. FP elimination always results in a
spill/reload if we have a shift-add insn where one operand is FP.
Hmm, are you saying it should NOT be generating
On 8/1/23 16:27, Jeff Law wrote:
On 8/1/23 17:13, Vineet Gupta wrote:
On 8/1/23 16:06, Philipp Tomsich wrote:
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
FWIW,
On 8/1/23 16:22, Jeff Law wrote:
They must not be working as expected or folks are using old trees.
Manolis's work for regcprop has been on the trunk for about 5-6 weeks
ag this point:
I have bleeding edge trunk from 2-3 days back. I think we are looking
for the following which the tree
On 8/1/23 17:13, Vineet Gupta wrote:
On 8/1/23 16:06, Philipp Tomsich wrote:
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
FWIW, all 5 of them involve a SH2ADD have
On 8/1/23 17:06, Philipp Tomsich wrote:
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
They must not be working as expected or folks are using old trees.
Manolis's work
On 8/1/23 17:03, Vineet Gupta wrote:
On 8/1/23 15:07, Philipp Tomsich wrote:
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
On 8/1/23 13:14, Vineet Gupta wrote:
I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
avoid the Thunderbird
On 8/1/23 16:06, Philipp Tomsich wrote:
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
FWIW, all 5 of them involve a SH2ADD have SP as source in the fold FP
case which
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
On Wed, 2 Aug 2023 at 01:03, Vineet Gupta wrote:
>
>
>
> On 8/1/23 15:07, Philipp Tomsich wrote:
> > +Manolis Tsamis
> >
> >
On 8/1/23 15:07, Philipp Tomsich wrote:
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
On 8/1/23 13:14, Vineet Gupta wrote:
I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
avoid the Thunderbird mangling the test formatting)
Thanks.
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/1/23 13:14, Vineet Gupta wrote:
>
> >
> > I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
> > avoid the Thunderbird mangling the test formatting)
> Thanks. Of particular importance
On 8/1/23 13:14, Vineet Gupta wrote:
I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
avoid the Thunderbird mangling the test formatting)
Thanks. Of particular importance is the leela change. My recollection
was that the f-m-o work also picked up that case. But if
Thank you for your effort.
I had evaluated only in intrate tests.
I am glad to see the same result on Leela.
On Tue, Aug 1, 2023 at 11:14 PM Vineet Gupta wrote:
>
>
> On 7/25/23 20:31, Jeff Law via Gcc-patches wrote:
> >
> >
> > On 7/25/23 05:24, Jivan Hakobyan wrote:
> >> Hi.
> >>
> >> I
On 7/25/23 20:31, Jeff Law via Gcc-patches wrote:
On 7/25/23 05:24, Jivan Hakobyan wrote:
Hi.
I re-run the benchmarks and hopefully got the same profit.
I also compared the leela's code and figured out the reason.
Actually, my and Manolis's patches do the same thing. The difference
is
On 7/25/23 05:24, Jivan Hakobyan wrote:
Hi.
I re-run the benchmarks and hopefully got the same profit.
I also compared the leela's code and figured out the reason.
Actually, my and Manolis's patches do the same thing. The difference is
only execution order.
But shouldn't your patch also
Hi.
I re-run the benchmarks and hopefully got the same profit.
I also compared the leela's code and figured out the reason.
Actually, my and Manolis's patches do the same thing. The difference is
only execution order.
Because of f-m-o held after the register allocation it cannot eliminate
On 7/12/23 14:59, Jivan Hakobyan via Gcc-patches wrote:
Accessing local arrays element turned into load form (fp + (index <<
C1)) + C2 address. In the case when access is in the loop we got loop
invariant computation. For some reason, moving out that part cannot
be done in loop-invariant
Accessing local arrays element turned into load form (fp + (index << C1)) +
C2 address.
In the case when access is in the loop we got loop invariant computation.
For some reason, moving out that part cannot be done in
loop-invariant passes.
But we can handle that in target-specific hook
21 matches
Mail list logo
