Hi Bin,
On 08/05/15 11:47, Bin Cheng wrote:
Hi,
GCC's IVO currently handles every IV use independently, which is not right
by learning from cases reported in PR65447.
The rationale is:
1) Lots of address type IVs refer to the same memory object, share similar
base and have same step. We
On Wed, May 27, 2015 at 11:44 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi Bin,
On 08/05/15 11:47, Bin Cheng wrote:
Hi,
GCC's IVO currently handles every IV use independently, which is not right
by learning from cases reported in PR65447.
The rationale is:
1) Lots of address type
On Thu, May 14, 2015 at 1:11 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, May 13, 2015 at 7:38 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, May 8, 2015 at 12:47 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
GCC's IVO currently handles every IV use independently, which is
On Wed, May 13, 2015 at 7:38 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, May 8, 2015 at 12:47 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
GCC's IVO currently handles every IV use independently, which is not right
by learning from cases reported in PR65447.
The rationale is:
On Fri, May 8, 2015 at 12:47 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
GCC's IVO currently handles every IV use independently, which is not right
by learning from cases reported in PR65447.
The rationale is:
1) Lots of address type IVs refer to the same memory object, share similar
base
Hi,
GCC's IVO currently handles every IV use independently, which is not right
by learning from cases reported in PR65447.
The rationale is:
1) Lots of address type IVs refer to the same memory object, share similar
base and have same step. We should handle these IVs as a group in order to
