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 f
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
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
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:D
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
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 testca
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
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 -O
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/el
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
>
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.
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, wh
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
13 matches
Mail list logo
