> >
> > loop iterations:(op0[ref offset: 192] changed || op0[ref offset: 256]
> > changed || op0[ref offset: 224] changed) && (op0[ref offset: 96] changed ||
> > op0[ref offset: 160] changed || op0[ref offset: 128] changed)
Looking at the testcase, loop stride is (op0[ref offset: 384] changed
> > ! set_hint_predicate (&inline_summary (node)->loop_iterations,
> > loop_iterations);
> > ! set_hint_predicate (&inline_summary (node)->loop_stride,
> > loop_stride);
> > scev_finalize ();
> > }
> > inline_summary (node)->self_time = time;
>
> Well, I know i's no
Hi,
On Wed, Sep 12, 2012 at 07:57:16PM +0200, Jan Hubicka wrote:
> Hi,
> for Fortran one of common reason to inline is because array descriptor is
> known and defines
> loop stride. This patch makes ipa-inline-analysis to notice these cases.
>
> Bootstrapped/regtested x86_64-linux, will commit
Jan Hubicka wrote:
for Fortran one of common reason to inline is because array descriptor is known
and defines
loop stride. This patch makes ipa-inline-analysis to notice these cases.
Thanks for your Fortran inlining work.
+ t(int s, void **p)
+ {
+ int i;
+ for (i;i<1;i+=s)
+ p
