Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 8/7/23 08:44, Manolis Tsamis wrote: I have sent out a new v4 of this (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html). In the new version I both restore the INSN_CODE as mentioned here and I also call recog when I commit the offset change (because there may be a change from no offset to some offsets). I have also removed the driver function as per Vineet's suggestion. Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in failing bootstrap on AArch64. The offending sequence looked like this (in 'simplified RTX'): (set (reg/f:DI 3 x3) (plus:DI (reg/f:DI 2 x2) (const_int 8 [0x8]))) (set (reg/f:DI 19 x19) (plus:DI (reg/f:DI 3 x3) (reg:DI 19 x19))) ... (set (reg:TI 2 x2) (mem:TI (reg/f:DI 0 x0))) (expr_list:REG_DEAD (reg/f:DI 0 x0) (expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19)) (nil))) (set (mem:TI (reg/f:DI 19 x19)) (reg:TI 2 x2)) (expr_list:REG_DEAD (reg/f:DI 19 x19) (expr_list:REG_DEAD (reg:TI 2 x2) (nil))) Were the first instruction (x3 = x2 + 8) was folded in the address calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI 19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was incorrect due to the modified runtime value of x19. For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot handle, so if any of them are involved we don't fold offsets. Although it would may be possible to improve this in the future, I think it's fine for now and the reduction of folded insns is a small %. I have tested v4 with a number of benchmarks and large projects on x64, aarch64 and riscv64 without observing any issues. The x86 testsuite issue still exists as I don't have a satisfactory solution to it yet. Any feedback for the changes is appreciated! Thanks for the explanation. You could just remove the REG_EQUIV note. It's not used much after allocation & reloading. Or just ignoring those insns as you've done seems reasonable as well. I doubt one approach is clear better than the other. jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
I have sent out a new v4 of this
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html).
In the new version I both restore the INSN_CODE as mentioned here and
I also call recog when I commit the offset change (because there may
be a change from no offset to some offsets).
I have also removed the driver function as per Vineet's suggestion.
Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in
failing bootstrap on AArch64.
The offending sequence looked like this (in 'simplified RTX'):
(set (reg/f:DI 3 x3)
(plus:DI (reg/f:DI 2 x2)
(const_int 8 [0x8])))
(set (reg/f:DI 19 x19)
(plus:DI (reg/f:DI 3 x3)
(reg:DI 19 x19)))
...
(set (reg:TI 2 x2)
(mem:TI (reg/f:DI 0 x0)))
(expr_list:REG_DEAD (reg/f:DI 0 x0)
(expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19))
(nil)))
(set (mem:TI (reg/f:DI 19 x19))
(reg:TI 2 x2))
(expr_list:REG_DEAD (reg/f:DI 19 x19)
(expr_list:REG_DEAD (reg:TI 2 x2)
(nil)))
Were the first instruction (x3 = x2 + 8) was folded in the address
calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI
19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was
incorrect due to the modified runtime value of x19.
For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot
handle, so if any of them are involved we don't fold offsets. Although
it would may be possible to improve this in the future, I think it's
fine for now and the reduction of folded insns is a small %.
I have tested v4 with a number of benchmarks and large projects on
x64, aarch64 and riscv64 without observing any issues. The x86
testsuite issue still exists as I don't have a satisfactory solution
to it yet.
Any feedback for the changes is appreciated!
Thanks,
Manolis
On Fri, Jul 21, 2023 at 12:59 AM Jeff Law wrote:
>
>
>
> On 7/20/23 00:18, Vineet Gupta wrote:
> >
> >
> > On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
> >>>
> >>> In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
> >>> grok'ed by cprop_hardreg,
> >>>
> >>> | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
> >>> |(const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
> >>> |(const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
> >>> {*movdf_hardfloat_rv64}
> >>> ^^^
> >>> | (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> >>> |(nil)))
> >>>
> >>> P.S. I wonder if it is a good idea in general to call recog() post
> >>> reload since the insn could be changed sufficiently to no longer
> >>> match the md patterns. Of course I don't know the answer.
> >> If this ever causes a problem, it's a backend bug. It's that simple.
> >>
> >> Conceptually it should always be safe to set INSN_CODE to -1 for any
> >> insn.
> >
> > Sure the -1 should be handled, but are you implying that f-mo- will
> > always generate a valid combination and recog() failing is simply a bug
> > in backend and/or f-m-o. If not, the -1 setting can potentially trigger
> > an ICE in future.
> A recog failure after setting INSN_CODE to -1 would always be an
> indicator of a target bug at the point where f-m-o runs.
>
> In that would be generally true as well. There are some very obscure
> exceptions and those exceptions are for narrow periods of time.
>
>
>
> >
> >>
> >> Odds are for this specific case in the RV backend, we just need a
> >> constraint to store 0.0 into a memory location. That can actually be
> >> implemented as a store from x0 since 0.0 has the bit pattern 0x0. This
> >> is probably a good thing to expose anyway as an optimization and can
> >> move forward independently of the f-m-o patch.
> >
> > I call dibs on this :-) Seems like an interesting little side project.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
> It's yours :-)
>
> jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/20/23 00:18, Vineet Gupta wrote:
On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
grok'ed by cprop_hardreg,
| (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
P.S. I wonder if it is a good idea in general to call recog() post
reload since the insn could be changed sufficiently to no longer
match the md patterns. Of course I don't know the answer.
If this ever causes a problem, it's a backend bug. It's that simple.
Conceptually it should always be safe to set INSN_CODE to -1 for any
insn.
Sure the -1 should be handled, but are you implying that f-mo- will
always generate a valid combination and recog() failing is simply a bug
in backend and/or f-m-o. If not, the -1 setting can potentially trigger
an ICE in future.
A recog failure after setting INSN_CODE to -1 would always be an
indicator of a target bug at the point where f-m-o runs.
In that would be generally true as well. There are some very obscure
exceptions and those exceptions are for narrow periods of time.
Odds are for this specific case in the RV backend, we just need a
constraint to store 0.0 into a memory location. That can actually be
implemented as a store from x0 since 0.0 has the bit pattern 0x0. This
is probably a good thing to expose anyway as an optimization and can
move forward independently of the f-m-o patch.
I call dibs on this :-) Seems like an interesting little side project.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
It's yours :-)
jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
grok'ed by cprop_hardreg,
| (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
P.S. I wonder if it is a good idea in general to call recog() post
reload since the insn could be changed sufficiently to no longer
match the md patterns. Of course I don't know the answer.
If this ever causes a problem, it's a backend bug. It's that simple.
Conceptually it should always be safe to set INSN_CODE to -1 for any
insn.
Sure the -1 should be handled, but are you implying that f-mo- will
always generate a valid combination and recog() failing is simply a bug
in backend and/or f-m-o. If not, the -1 setting can potentially trigger
an ICE in future.
Odds are for this specific case in the RV backend, we just need a
constraint to store 0.0 into a memory location. That can actually be
implemented as a store from x0 since 0.0 has the bit pattern 0x0.
This is probably a good thing to expose anyway as an optimization and
can move forward independently of the f-m-o patch.
I call dibs on this :-) Seems like an interesting little side project.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
-Vineet
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/19/23 02:08, Manolis Tsamis wrote: de. I stumbled upon the same thing when doing an aarch64 bootstrap build yesterday. Given that this causes issues, maybe doing int icode = INSN_CODE (insn); ... INSN_CODE (insn) = icode; Is a good option and should also be more performant. I nearly suggested you do something like this, but ultimately it's a workaround for target bugs. So part of me wants to keep it as is, but I can also understand the desire to make a chance like you've suggesting. Even with that I'm still getting a segfault while doing a bootstrap build that I'm investigating. Sounds good. I still need to drop the V3 into my tester and validate the m68k (and everything else) just works. I'm slightly concerned about SH, but it's still failing even after taking the V2 out of the tester, so the SH issues are clearly unrelated to f-m-o. I'll take Vineet's testcase and verify that we can just use an integer store to handle the 0.0 case. As I mentioned, that's the right thing to do anyway from both a correctness and performance standpoint. I'll also review the movsf pattern for the same problem/optimization. jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
Hi Vineet, Jeff,
On Wed, Jul 19, 2023 at 7:31 AM Jeff Law wrote:
>
>
>
> On 7/18/23 17:42, Vineet Gupta wrote:
> > Hi Manolis,
> >
> > On 7/18/23 11:01, Jeff Law via Gcc-patches wrote:
> >> Vineet @ Rivos has indicated he stumbled across an ICE with the V3
> >> code. Hopefully he'll get a testcase for that extracted shortly.
> >
> > Yeah, I was trying to build SPEC2017 with this patch and ran into ICE
> > for several of them with -Ofast build: The reduced test from 455.nab is
> > attached here.
> > The issue happens with v2 as well, so not something introduced by v3.
> >
> > There's ICE in cprop_hardreg which immediately follows f-m-o.
> >
> >
> > The protagonist is ins 93 which starts off in combine as a simple set of
> > a DF 0.
> >
> > | sff.i.288r.combine:(insn 93 337 94 8 (set (reg/v:DF 236 [ e ])
> > | sff.i.288r.combine- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11
> > 190 {*movdf_hardfloat_rv64}
> >
> > Subsequently reload transforms it into SP + offset
> >
> > | sff.i.303r.reload:(insn 93 337 94 9 (set (mem/c:DF (plus:DI (reg/f:DI
> > 2 sp)
> > | sff.i.303r.reload- (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
> > | sff.i.303r.reload- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
> > {*movdf_hardfloat_rv64}
> > | sff.i.303r.reload- (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> >
> > It gets processed by f-m-o and lands in cprop_hardreg, where it triggers
> > ICE.
> >
> > | (insn 93 337 523 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
> > | (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
> > | (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 -1
> > ^^^
> > | (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> > |(nil)))
> > | during RTL pass: cprop_hardreg
> >
> > Here's my analysis:
> >
> > f-m-o: do_check_validity() -> insn_invalid_p() tries to recog() a
> > modified version of insn 93 (actually there is no change, so perhaps
> > something we can optimize later). The corresponding md pattern
> > movdf_hardfloat_rv64 no longer matches since it expects REG_P for
> > operand0, while reload has converted it into SP + offset. f-m-o then
> > does the right thing by invalidating INSN_CODE=-1 for a subsequent
> > recog() to work correctly.
> > But it seems this -1 lingers into the next pass, and trips up
> > copyprop_hardreg_forward_1() -> extract_constrain_insn()
> > So I don't know what the right fix here should be.
> This is a bug in the RISC-V backend. I actually fixed basically the
> same bug in another backend that was exposed by the f-m-o code.
>
I stumbled upon the same thing when doing an aarch64 bootstrap build yesterday.
Given that this causes issues, maybe doing
int icode = INSN_CODE (insn);
...
INSN_CODE (insn) = icode;
Is a good option and should also be more performant.
Even with that I'm still getting a segfault while doing a bootstrap
build that I'm investigating.
>
> >
> > In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
> > grok'ed by cprop_hardreg,
> >
> > | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
> > |(const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
> > |(const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
> > {*movdf_hardfloat_rv64}
> > ^^^
> > | (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> > |(nil)))
> >
> > P.S. I wonder if it is a good idea in general to call recog() post
> > reload since the insn could be changed sufficiently to no longer match
> > the md patterns. Of course I don't know the answer.
> If this ever causes a problem, it's a backend bug. It's that simple.
>
> Conceptually it should always be safe to set INSN_CODE to -1 for any insn.
>
> Odds are for this specific case in the RV backend, we just need a
> constraint to store 0.0 into a memory location. That can actually be
> implemented as a store from x0 since 0.0 has the bit pattern 0x0. This
> is probably a good thing to expose anyway as an optimization and can
> move forward independently of the f-m-o patch.
>
>
>
> >
> > P.S.2 When debugging code, I noticed a minor annoyance in the patch with
> > the whole fold_mem_offsets_driver() switch-case indirection. It doesn't
> > seem to be serving any purpose, and we could simply call corresponding
> > do_* routines in execute () itself.
> We were in the process of squashing some of this out of the
> implementation. I hadn't looked at the V3 patch to see how much
> progress had been made on this yet.
>
Thanks for pointing that out Vineet!
When I refactored the code in the separate do_* functions it never
occured to me that both the _driver function and the state enum are
now useless. I will remove all of this in the next iteration.
Manolis
> Thanks for digging into this!
>
> jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/18/23 17:42, Vineet Gupta wrote:
Hi Manolis,
On 7/18/23 11:01, Jeff Law via Gcc-patches wrote:
Vineet @ Rivos has indicated he stumbled across an ICE with the V3
code. Hopefully he'll get a testcase for that extracted shortly.
Yeah, I was trying to build SPEC2017 with this patch and ran into ICE
for several of them with -Ofast build: The reduced test from 455.nab is
attached here.
The issue happens with v2 as well, so not something introduced by v3.
There's ICE in cprop_hardreg which immediately follows f-m-o.
The protagonist is ins 93 which starts off in combine as a simple set of
a DF 0.
| sff.i.288r.combine:(insn 93 337 94 8 (set (reg/v:DF 236 [ e ])
| sff.i.288r.combine- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11
190 {*movdf_hardfloat_rv64}
Subsequently reload transforms it into SP + offset
| sff.i.303r.reload:(insn 93 337 94 9 (set (mem/c:DF (plus:DI (reg/f:DI
2 sp)
| sff.i.303r.reload- (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| sff.i.303r.reload- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
| sff.i.303r.reload- (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
It gets processed by f-m-o and lands in cprop_hardreg, where it triggers
ICE.
| (insn 93 337 523 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 -1
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
| during RTL pass: cprop_hardreg
Here's my analysis:
f-m-o: do_check_validity() -> insn_invalid_p() tries to recog() a
modified version of insn 93 (actually there is no change, so perhaps
something we can optimize later). The corresponding md pattern
movdf_hardfloat_rv64 no longer matches since it expects REG_P for
operand0, while reload has converted it into SP + offset. f-m-o then
does the right thing by invalidating INSN_CODE=-1 for a subsequent
recog() to work correctly.
But it seems this -1 lingers into the next pass, and trips up
copyprop_hardreg_forward_1() -> extract_constrain_insn()
So I don't know what the right fix here should be.
This is a bug in the RISC-V backend. I actually fixed basically the
same bug in another backend that was exposed by the f-m-o code.
In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
grok'ed by cprop_hardreg,
| (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
P.S. I wonder if it is a good idea in general to call recog() post
reload since the insn could be changed sufficiently to no longer match
the md patterns. Of course I don't know the answer.
If this ever causes a problem, it's a backend bug. It's that simple.
Conceptually it should always be safe to set INSN_CODE to -1 for any insn.
Odds are for this specific case in the RV backend, we just need a
constraint to store 0.0 into a memory location. That can actually be
implemented as a store from x0 since 0.0 has the bit pattern 0x0. This
is probably a good thing to expose anyway as an optimization and can
move forward independently of the f-m-o patch.
P.S.2 When debugging code, I noticed a minor annoyance in the patch with
the whole fold_mem_offsets_driver() switch-case indirection. It doesn't
seem to be serving any purpose, and we could simply call corresponding
do_* routines in execute () itself.
We were in the process of squashing some of this out of the
implementation. I hadn't looked at the V3 patch to see how much
progress had been made on this yet.
Thanks for digging into this!
jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
Hi Manolis,
On 7/18/23 11:01, Jeff Law via Gcc-patches wrote:
Vineet @ Rivos has indicated he stumbled across an ICE with the V3
code. Hopefully he'll get a testcase for that extracted shortly.
Yeah, I was trying to build SPEC2017 with this patch and ran into ICE
for several of them with -Ofast build: The reduced test from 455.nab is
attached here.
The issue happens with v2 as well, so not something introduced by v3.
There's ICE in cprop_hardreg which immediately follows f-m-o.
The protagonist is ins 93 which starts off in combine as a simple set of
a DF 0.
| sff.i.288r.combine:(insn 93 337 94 8 (set (reg/v:DF 236 [ e ])
| sff.i.288r.combine- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11
190 {*movdf_hardfloat_rv64}
Subsequently reload transforms it into SP + offset
| sff.i.303r.reload:(insn 93 337 94 9 (set (mem/c:DF (plus:DI (reg/f:DI
2 sp)
| sff.i.303r.reload- (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| sff.i.303r.reload- (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
| sff.i.303r.reload- (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
It gets processed by f-m-o and lands in cprop_hardreg, where it triggers
ICE.
| (insn 93 337 523 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 -1
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
| during RTL pass: cprop_hardreg
Here's my analysis:
f-m-o: do_check_validity() -> insn_invalid_p() tries to recog() a
modified version of insn 93 (actually there is no change, so perhaps
something we can optimize later). The corresponding md pattern
movdf_hardfloat_rv64 no longer matches since it expects REG_P for
operand0, while reload has converted it into SP + offset. f-m-o then
does the right thing by invalidating INSN_CODE=-1 for a subsequent
recog() to work correctly.
But it seems this -1 lingers into the next pass, and trips up
copyprop_hardreg_forward_1() -> extract_constrain_insn()
So I don't know what the right fix here should be.
In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
grok'ed by cprop_hardreg,
| (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
| (const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
| (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
{*movdf_hardfloat_rv64}
^^^
| (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
| (nil)))
P.S. I wonder if it is a good idea in general to call recog() post
reload since the insn could be changed sufficiently to no longer match
the md patterns. Of course I don't know the answer.
P.S.2 When debugging code, I noticed a minor annoyance in the patch with
the whole fold_mem_offsets_driver() switch-case indirection. It doesn't
seem to be serving any purpose, and we could simply call corresponding
do_* routines in execute () itself.
Thx,
-Vineeta, c, d, g, h, i, j, k, m, p, q, r, aa, t, u, x;
double *f, *s;
double l, n, o, v, w;
b() {
double e, ad, ae, af, ag, ah, ai, aj, am, an, ap, aq, ar, as, at, av, aw;
for (; q; q = aa) {
r = f[x];
ah = f[r + 2] - g;
af = f[0] - f[r];
ag = 1 - f[r + 1];
av = ae * af * ah * ai;
aj = h - w * p * ah;
am = o + av * af;
an = j * o * av * ag;
ap = (am - m) * ad * (k - an - n) * a - v * c;
ar = (aj - l) * c;
if (a)
;
else
az:
switch (d) {
case 1:
e = aw * i;
break;
case 2:
exit(1);
}
s[0] = ap;
t += at * aq;
u = as += at * ar;
if (c)
goto az;
}
return e;
}
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/18/23 11:15, Manolis Tsamis wrote: On Fri, Jul 14, 2023 at 8:35 AM Jeff Law wrote: On 7/13/23 09:05, Manolis Tsamis wrote: In this version I have made f-m-o able to also eliminate constant moves in addition to the add constant instructions. This increases the number of simplified/eliminated instructions and is a good addition for RISC style ISAs where these are more common. This has led to pr52146.c failing in x86, which I haven't been able to find a way to fix. This involves directly writing to a constant address with -mx32 The code movl$-18874240, %eax movl$0, (%eax) is 'optimized' to movl$0, %eax movl$0, -18874240(%eax) Which is actually movl$0, -18874240 which is wrong per the ticket. The fix for the ticket involved changes to legitimate_address_p which f-m-o does call but it doesn't reject due to the existence of (%eax) which in turn is actually zero. I believe this is not strictly an f-m-o issue since the pass calls all the required functions to test whether the newly synthesized memory instruction is valid. Any ideas on how to solve this issue is appreciated. I wonder if costing might be useful here. I would expect the 2nd sequence is the most costly of the three if address costing models are reasonably accurate. Another way would be to look at the length of the memory reference insn. If it's larger, then it's likely more costly. That's what I've got off the top of my head. I could test whether the cost function prefers the version that we want, but that would be a workaround I would like to avoid. It may also be the case that this reproduces with a different sequence where the unwanted code is actually more profitable. I was trying to find out whether the original fix can be extended in a way that solves this, because having an address that is reported as legitimate but is actually not could also create issues elsewhere. But I don't yet have a suggestion on how to fix it yet. I was thinking a bit more about this yesterday, and even in the case where the new mem crosses a boundary thus making the memory load/store more expensive I think we're still OK. The key is at worst we will have changed an earlier instruction like t = sp + into t = sp which should reduce the cost of that earlier instruction. And I would expect the vast majority of the time we completely eliminate that earlier instruction. So this may ultimately be a non-issue. Vineet @ Rivos has indicated he stumbled across an ICE with the V3 code. Hopefully he'll get a testcase for that extracted shortly. jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On Fri, Jul 14, 2023 at 8:35 AM Jeff Law wrote: > > > > On 7/13/23 09:05, Manolis Tsamis wrote: > > In this version I have made f-m-o able to also eliminate constant > > moves in addition to the add constant instructions. > > This increases the number of simplified/eliminated instructions and is > > a good addition for RISC style ISAs where these are more common. > > > > This has led to pr52146.c failing in x86, which I haven't been able to > > find a way to fix. > > This involves directly writing to a constant address with -mx32 > > > > The code > > movl$-18874240, %eax > > movl$0, (%eax) > > > > is 'optimized' to > > movl$0, %eax > > movl$0, -18874240(%eax) > > > > Which is actually > > movl$0, -18874240 > > > > which is wrong per the ticket. > > The fix for the ticket involved changes to legitimate_address_p which > > f-m-o does call but it doesn't reject due to the existence of (%eax) > > which in turn is actually zero. > > I believe this is not strictly an f-m-o issue since the pass calls all > > the required functions to test whether the newly synthesized memory > > instruction is valid. > > > > Any ideas on how to solve this issue is appreciated. > I wonder if costing might be useful here. I would expect the 2nd > sequence is the most costly of the three if address costing models are > reasonably accurate. > > Another way would be to look at the length of the memory reference insn. > If it's larger, then it's likely more costly. > > That's what I've got off the top of my head. > I could test whether the cost function prefers the version that we want, but that would be a workaround I would like to avoid. It may also be the case that this reproduces with a different sequence where the unwanted code is actually more profitable. I was trying to find out whether the original fix can be extended in a way that solves this, because having an address that is reported as legitimate but is actually not could also create issues elsewhere. But I don't yet have a suggestion on how to fix it yet. Thanks, Manolis > Jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 7/13/23 09:05, Manolis Tsamis wrote: In this version I have made f-m-o able to also eliminate constant moves in addition to the add constant instructions. This increases the number of simplified/eliminated instructions and is a good addition for RISC style ISAs where these are more common. This has led to pr52146.c failing in x86, which I haven't been able to find a way to fix. This involves directly writing to a constant address with -mx32 The code movl$-18874240, %eax movl$0, (%eax) is 'optimized' to movl$0, %eax movl$0, -18874240(%eax) Which is actually movl$0, -18874240 which is wrong per the ticket. The fix for the ticket involved changes to legitimate_address_p which f-m-o does call but it doesn't reject due to the existence of (%eax) which in turn is actually zero. I believe this is not strictly an f-m-o issue since the pass calls all the required functions to test whether the newly synthesized memory instruction is valid. Any ideas on how to solve this issue is appreciated. I wonder if costing might be useful here. I would expect the 2nd sequence is the most costly of the three if address costing models are reasonably accurate. Another way would be to look at the length of the memory reference insn. If it's larger, then it's likely more costly. That's what I've got off the top of my head. Jeff
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
In this version I have made f-m-o able to also eliminate constant moves in addition to the add constant instructions. This increases the number of simplified/eliminated instructions and is a good addition for RISC style ISAs where these are more common. This has led to pr52146.c failing in x86, which I haven't been able to find a way to fix. This involves directly writing to a constant address with -mx32 The code movl$-18874240, %eax movl$0, (%eax) is 'optimized' to movl$0, %eax movl$0, -18874240(%eax) Which is actually movl$0, -18874240 which is wrong per the ticket. The fix for the ticket involved changes to legitimate_address_p which f-m-o does call but it doesn't reject due to the existence of (%eax) which in turn is actually zero. I believe this is not strictly an f-m-o issue since the pass calls all the required functions to test whether the newly synthesized memory instruction is valid. Any ideas on how to solve this issue is appreciated. Manolis On Thu, Jul 13, 2023 at 5:13 PM Manolis Tsamis wrote: > > This is a new RTL pass that tries to optimize memory offset calculations > by moving them from add immediate instructions to the memory loads/stores. > For example it can transform this: > > addi t4,sp,16 > add t2,a6,t4 > shl t3,t2,1 > ld a2,0(t3) > addi a2,1 > sd a2,8(t2) > > into the following (one instruction less): > > add t2,a6,sp > shl t3,t2,1 > ld a2,32(t3) > addi a2,1 > sd a2,24(t2) > > Although there are places where this is done already, this pass is more > powerful and can handle the more difficult cases that are currently not > optimized. Also, it runs late enough and can optimize away unnecessary > stack pointer calculations. > > gcc/ChangeLog: > > * Makefile.in: Add fold-mem-offsets.o. > * passes.def: Schedule a new pass. > * tree-pass.h (make_pass_fold_mem_offsets): Declare. > * common.opt: New options. > * doc/invoke.texi: Document new option. > * fold-mem-offsets.cc: New file. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/fold-mem-offsets-1.c: New test. > * gcc.target/riscv/fold-mem-offsets-2.c: New test. > * gcc.target/riscv/fold-mem-offsets-3.c: New test. > > Signed-off-by: Manolis Tsamis > --- > > Changes in v3: > - Added propagation for more codes: > sub, neg, mul. > - Added folding / elimination for sub and > const int moves. > - For the validity check of the generated addresses > also test memory_address_addr_space_p. > - Replaced GEN_INT with gen_int_mode. > - Replaced some bitmap_head with auto_bitmap. > - Refactor each phase into own function for readability. > - Add dump details. > - Replace rtx iteration with reg_mentioned_p. > - Return early for codes that we can't propagate through. > > gcc/Makefile.in | 1 + > gcc/common.opt| 4 + > gcc/doc/invoke.texi | 8 + > gcc/fold-mem-offsets.cc | 749 ++ > gcc/passes.def| 1 + > .../gcc.target/riscv/fold-mem-offsets-1.c | 16 + > .../gcc.target/riscv/fold-mem-offsets-2.c | 24 + > .../gcc.target/riscv/fold-mem-offsets-3.c | 17 + > gcc/tree-pass.h | 1 + > 9 files changed, 821 insertions(+) > create mode 100644 gcc/fold-mem-offsets.cc > create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-1.c > create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-2.c > create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-3.c > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index c478ec85201..6a5c2915133 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -1430,6 +1430,7 @@ OBJS = \ > fixed-value.o \ > fold-const.o \ > fold-const-call.o \ > + fold-mem-offsets.o \ > function.o \ > function-abi.o \ > function-tests.o \ > diff --git a/gcc/common.opt b/gcc/common.opt > index 25f650e2dae..901947f1db5 100644 > --- a/gcc/common.opt > +++ b/gcc/common.opt > @@ -1248,6 +1248,10 @@ fcprop-registers > Common Var(flag_cprop_registers) Optimization > Perform a register copy-propagation optimization pass. > > +ffold-mem-offsets > +Target Bool Var(flag_fold_mem_offsets) Init(1) > +Fold instructions calculating memory offsets to the memory access > instruction if possible. > + > fcrossjumping > Common Var(flag_crossjumping) Optimization > Perform cross-jumping optimization. > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index cbc1282c274..dc4e6922bb5 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -539,6 +539,7 @@ Objective-C and Objective-C++ Dialects}. > -fauto-inc-dec -fbranch-probabilities > -fcaller-saves >
[PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following (one instruction less):
add t2,a6,sp
shl t3,t2,1
ld a2,32(t3)
addi a2,1
sd a2,24(t2)
Although there are places where this is done already, this pass is more
powerful and can handle the more difficult cases that are currently not
optimized. Also, it runs late enough and can optimize away unnecessary
stack pointer calculations.
gcc/ChangeLog:
* Makefile.in: Add fold-mem-offsets.o.
* passes.def: Schedule a new pass.
* tree-pass.h (make_pass_fold_mem_offsets): Declare.
* common.opt: New options.
* doc/invoke.texi: Document new option.
* fold-mem-offsets.cc: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fold-mem-offsets-1.c: New test.
* gcc.target/riscv/fold-mem-offsets-2.c: New test.
* gcc.target/riscv/fold-mem-offsets-3.c: New test.
Signed-off-by: Manolis Tsamis
---
Changes in v3:
- Added propagation for more codes:
sub, neg, mul.
- Added folding / elimination for sub and
const int moves.
- For the validity check of the generated addresses
also test memory_address_addr_space_p.
- Replaced GEN_INT with gen_int_mode.
- Replaced some bitmap_head with auto_bitmap.
- Refactor each phase into own function for readability.
- Add dump details.
- Replace rtx iteration with reg_mentioned_p.
- Return early for codes that we can't propagate through.
gcc/Makefile.in | 1 +
gcc/common.opt| 4 +
gcc/doc/invoke.texi | 8 +
gcc/fold-mem-offsets.cc | 749 ++
gcc/passes.def| 1 +
.../gcc.target/riscv/fold-mem-offsets-1.c | 16 +
.../gcc.target/riscv/fold-mem-offsets-2.c | 24 +
.../gcc.target/riscv/fold-mem-offsets-3.c | 17 +
gcc/tree-pass.h | 1 +
9 files changed, 821 insertions(+)
create mode 100644 gcc/fold-mem-offsets.cc
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-3.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c478ec85201..6a5c2915133 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1430,6 +1430,7 @@ OBJS = \
fixed-value.o \
fold-const.o \
fold-const-call.o \
+ fold-mem-offsets.o \
function.o \
function-abi.o \
function-tests.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index 25f650e2dae..901947f1db5 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1248,6 +1248,10 @@ fcprop-registers
Common Var(flag_cprop_registers) Optimization
Perform a register copy-propagation optimization pass.
+ffold-mem-offsets
+Target Bool Var(flag_fold_mem_offsets) Init(1)
+Fold instructions calculating memory offsets to the memory access instruction
if possible.
+
fcrossjumping
Common Var(flag_crossjumping) Optimization
Perform cross-jumping optimization.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index cbc1282c274..dc4e6922bb5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -539,6 +539,7 @@ Objective-C and Objective-C++ Dialects}.
-fauto-inc-dec -fbranch-probabilities
-fcaller-saves
-fcombine-stack-adjustments -fconserve-stack
+-ffold-mem-offsets
-fcompare-elim -fcprop-registers -fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules
-fcx-limited-range
@@ -14293,6 +14294,13 @@ the comparison operation before register allocation is
complete.
Enabled at levels @option{-O1}, @option{-O2}, @option{-O3}, @option{-Os}.
+@opindex ffold-mem-offsets
+@item -ffold-mem-offsets
+@itemx -fno-fold-mem-offsets
+Try to eliminate add instructions by folding them in memory loads/stores.
+
+Enabled at levels @option{-O2}, @option{-O3}.
+
@opindex fcprop-registers
@item -fcprop-registers
After register allocation and post-register allocation instruction splitting,
diff --git a/gcc/fold-mem-offsets.cc b/gcc/fold-mem-offsets.cc
new file mode 100644
index 000..a27c9ab18a4
--- /dev/null
+++ b/gcc/fold-mem-offsets.cc
@@ -0,0 +1,749 @@
+/* Late RTL pass to fold memory offsets.
+ Copyright (C) 2023 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT
