This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Find more cases for AUTO_INC_DEC
- From: Adam Nemet <anemet at lnxw dot com>
- To: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 2 Aug 2005 10:56:14 -0700
- Subject: Re: [PATCH] Find more cases for AUTO_INC_DEC
- References: <email@example.com><20050717024906.GA15372@redhat.com><firstname.lastname@example.org>
> Richard Henderson writes:
>> Have a look at Joern's large auto-increment patch.
> OK, I did. It does not fix the basic testcase. It seems to me that
> unless recognize_related_for_insn creates an entry in rel_base_list
> nothing gets optimized in optmize_relate_values_0. In the testcase,
> insns that set up potentially related registers are hard regs and
> recognize_related_for_insn ignores those. It is not clear if this is
> just a temporary limitation but this prevents any related-value
> optmization on the testcase.
> But in my opinion even if this pass could deal with all auto-increment
> opportunities the real question is whether it will supersede the basic
> auto-increment optimization in flow. I assume it would not. All the
> required information to do the tranformation there is readily
> avaiable: reg_next_use is used to set up LOG_LINKs not just for
> AUTO_INC. And if I am correct so far then my patch just takes another
> look at the same reg_next_use information in terms of the RHS of the
> addition: (r = p + 1; *(p + 1)), if P's next use is the address
> expression then we can substitute R there and then do the basic
> auto-increment optimization assuming R is not used or set in between.
> This results in 52% more auto-increment optimizations during a
> ppc-darwin bootstrap.
> In the meantime, I also tested arm-elf on the simulator with no
> regression. On ARM the basic testcase behaves similarly after the
> str r1, [r0, #4]
> add r0, r0, #4
> bx lr
> str r1, [r0, #4]!
> bx lr
It's been two weeks since my response, so this is just a reminder
email. The patch is here: