Hi,
> >> > If a pointer typed use is plainly value passed to a func call, it is
> >> > not an address use, right? But as you said, x86 lea may help here.
> >>
> >> But that's what you are matching ... (well, for builtins you know
> >> will expand that to a memory reference).
> >>
> >> What I disli
Hi,
> > If a pointer typed use is plainly value passed to a func call, it is
> > not an address use, right? But as you said, x86 lea may help here.
>
> But that's what you are matching ... (well, for builtins you know
> will expand that to a memory reference).
>
> What I dislike in the patch is
Hi,
> This patch works on the intrinsic calls handling issue in IVOPT mentioned
> here:
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>
> In find_interesting_uses_stmt, it changes
>
> arg = expr
> __builtin_xxx (arg)
>
> to
>
> arg = expr;
> tmp = addr_expr (mem_ref(arg));
> __bui
Hi,
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>
> PR tree-optimization/57343
> * tree-ssa-loop-niter.c (number_of_iterations_ne_max): Do not
> use multiple_of_p if not TYPE_OVERFLOW_UNDEFINED.
> (number_of_iterations_cond): Do not build the folde
Hi,
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Zdenek, does this look ok? double_int_constant_multiple_p seems to
> be only used from aff_combination_constant_multiple_p.
yes,
Zdenek
Hi,
> > I realize you're trying to do the same, but by using the SESE copier, you're
> > implicitly trying to do an incremental update. I think you're going to
> > really need to look at the assumptions of that code and verify that the
> > switch FSA optimization doesn't violate those assumptions
Hi,
> > > We ICEd on attached testcase because we didn't properly detected the
> > > latch edge. Furthermore, I think the code for re-computing latches
> > > is somehow broken at the moment. In fix_loop_structure we have
> > > /* If there was no latch, schedule the loop for removal. */
>
Hi,
> We ICEd on attached testcase because we didn't properly detected the
> latch edge. Furthermore, I think the code for re-computing latches
> is somehow broken at the moment. In fix_loop_structure we have
> /* If there was no latch, schedule the loop for removal. */
> if (!first
Hi,
> > Yes, you should check whether you are in an irreducible loop. This is done
> > by
> > testing EDGE_IRREDUCIBLE_LOOP flag,
>
> Alright, I was wondering whether there's any other way. Unfortunately,
> here I couldn't do something like
>
> if (loop_preheader_edge (loop)->flags & EDGE_IRR
Hi,
> On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote:
> > I agree -- at the very least, unswitch_single_loop should check whether
> > there
> > is any possiblity it could have affected irreducible loops information (this
> > should only be the case
Hi,
> On Thu, Jan 10, 2013 at 6:31 PM, Marek Polacek wrote:
> > + /* We changed the CFG. Recompute irreducible BBs and edges. */
> > + mark_irreducible_loops ();
>
> This is a very expensive fix for a really unusual situation.
>
> I don't think this is the right thing to do...
I agree -- at
Hi,
> When one (or both) IVs have extend_mode wider than mode, but step doesn't
> fit into mode (the IV is
> (subreg:MODE (plus:EXTEND_MODE base (mult:EXTEND_MODE i step)) lowpart)
> ), such as for EXTEND_MODE SImode, MODE QImode and step e.g. 129, 128, 256
> or 517, iv_number_of_iterations can cr
Hi,
> >> I think tree-ssa-loop-ivopts is simply
> >> asking for the wrong thing, and needs to be changed. As I say,
> >> Sandra had some fixes in this area.
> >
> > This patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
> >
> > Sadly, that patch has fallen off the bottom o
> Quoting Zdenek Dvorak :
>
> >no -- you should also test that latch contains no active insns.
> >I.e., factorize
> >out whatever forwarder_block_p does except for the test
> >"(dest->loop_father->header == dest)" test,
>
> Like this?
>
&
Hi,
> The loop appears to be entered at the top, yet both my original and your test
> fail.
>
> Looking what happens with your test in more detail, I find that
>
> loop->latch == desc->in_edge->dest
>
> is true, but forwarder_block_p (loop->latch) fails:
>
> 562 if (dest->loop_fathe
Hi,
> 2012-09-26 J"orn Rennecke
>
> * loop-doloop.c (doloop_modify): Pass doloop_end pattern to
> gen_doloop_begin.
> * loop-doloop.c (doloop_optimize): Pass flag to indicate if loop is
> entered at top to gen_doloop_end.
> * config/arm/thumb2.md (doloop_e
Hi,
> > (7) If the computed address cost turns out to be 0, the current code
> > (for some unknown reason) is turning that into 1, which can screw up
> > the relative costs of address computations vs other operations like
> > addition.
> >
> > I've come up with the attached patch to try to fix the
Hi,
> Ok with these changes if you give Zdenek 24h to comment, too.
fine with me,
Zdenek
Hello,
> On 03/16/2012 02:46 PM, Richard Guenther wrote:
> > In the end what we want is a POINTER_PLUS_EXPR variant
> > that does not make alias-analysis assume the result still points
> > to within the objects the pointer pointed to before the increment/decrement.
>
> Hold on, is alias analysis
> >> Yes, that could work. ?Though it might end up being incredibly ugly ;)
> >
> > In the code? Should really only change a few lines in the patch I would
> > have thought. I'll get back to you when I have a new version - thanks
> > for the tip.
>
> No, in the GIMPLE IL.
>
> Richard.
And I can
Hi,
> > Well, what are our rules for whether overflow on POINTER_PLUS_EXPR is
> > defined or not? A quick search through the headers and docs doesn't turn
> > up anything. Would there be a downside to defining it as wrapping?
> >
> > Can you show an example where a POINTER_PLUS_EXPR produced by i
Hi,
> Currently, tree-ssa-loop-ivopts assumes that pointers and integers can
> be used interchangeably. It prefers to compute everything in unsigned
> integer types rather than pointer types.
> On a new target that I'm working on, this assumption is problematic;
> casting a pointer to an integer a
Hi,
> On Tue, Mar 13, 2012 at 7:31 PM, Andrew Pinski wrote:
> > Ping? Rebootstrapped on x86_64-linux-gnu with no regressions.
>
> Zdenek, can you have a look here? I think the patch is reasonable, but
> you should have a better idea ;)
I do not understand the patch very well. In the comment
Hi,
> It seems loop-iv.c happily creates shared RTL in lots of places,
> loop-unroll.c solves that by unsharing everything it adds, this is
> an attempt to do the same in unswitching to unshare everything iv_analyze
> came up with.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
Hi,
> --- 316,333
>normally. We may assume that e->dest is not a header of any loop,
>as it now has exactly one predecessor. */
> while (loop_outer (e->src->loop_father)
> ! && dominated_by_p (CDI_DOMINATORS,
> !e->src->loop_father->l
Hi,
> Just a nit, can't you break out of the loop when irred_invalidated is set to
> true as well? There is no need to look through any further edges. I.e.
> perhaps:
> if (!irred_invalidated)
> FOR_EACH_EDGE (ae, ei, e->src->succs)
> if (ae != e
> && ae->dest != EXIT_BLOCK_P
Hi,
> The attached patch fixes PR50322.
>
> The test-case is supposed to succeed if the loop counter data-type has the
> same
> size as a pointer. The patch defines TYPE to be an int datatype of the same
> size
> as a pointer, and uses it. After this fix, there's no need for the avr xfails
> an
Hi,
> here's the updated version of the patch.
>
> The goal is to remove the 'i' iterator from the following example, by
> replacing 'i < n' with 'p < base + n'.
>
> void
> f (char *base, unsigned long int i, unsigned long int n)
> {
> char *p = base + i;
> do
> {
> *p = '\0';
>
Hi,
> * tree-ssa-loop-niter.c (number_of_iterations_ne): Use the signed types
> for the trivial case, then convert to unsigned.
> (number_of_iterations_lt): Use the original signed types.
> (number_of_iterations_cond): Same.
> (find_loop_niter): Build signed integer c
Hi,
> >> It'll collide with Sebastians patch in that area. I suggested a
> >> INTEGRAL_TYPE_P check instead of the simple_iv one, it
> >> should be cheaper. Zdenek, do you think it will be "incorrect"
> >> in some cases?
> >
> > well, it does not make much sense -- reductions of integral type wo
Hi,
> > This patch fixes the build failure of cactusADM and dealII spec2006
> > benchmarks when autopar is enabled.
> > (for powerpc they fail only when -m32 is additionally enabled)
> >
> > The problem originated in canonicalize_loop_ivs, where we iterate the
> > header's phis in order to base al
Hi,
> I moved the adjustment of the loop's iterations from
> gimple_duplicate_sese_tail
> to tree-parloops.c, right before the call to gimple_duplicate_sese_tail.
> I repeated the bootstrap, regression and spec runs - no new regressions.
>
> OK to commit?
OK,
Zdenek
> Index: gcc/tree-parloops
Hi,
> This patch fixes the build failure of gcc spec2006 benchmark.
> The change is in gimple_duplicate_sese_tail(), where we need to subtract
> 1 from the loop's number of iterations.
> The stmt created to change the rhs of the loop's condition, used to be
> inserted right after the defining s
> > I don't think we should move this kind of undefinedness from C to
> > the GIMPLE semantics. What do other languages allow that
> > we have to support (what did K&R C specify?).
>
> I don't think there is a formal specification of K&R C, just the (somewhat
> informal) book. On topic of pointe
> I don't think we should move this kind of undefinedness from C to
> the GIMPLE semantics. What do other languages allow that
> we have to support (what did K&R C specify?).
I don't think there is a formal specification of K&R C, just the (somewhat
informal) book. On topic of pointer arithmetic
Hi,
> >> >> > Index: tree-vrp.c
> >> >> > ===
> >> >> > --- tree-vrp.c (revision 173703)
> >> >> > +++ tree-vrp.c (working copy)
> >> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> >> > {
> >> >> >
Hi,
> >> > Index: tree-vrp.c
> >> > ===
> >> > --- tree-vrp.c (revision 173703)
> >> > +++ tree-vrp.c (working copy)
> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> > {
> >> > /* For point
> >> Interesting. I'd never thought about the generation/use angle to prove
> >> a pointer was non-null. ISTM we could use that same logic to infer that
> >> more pointers are non-null in extract_range_from_binary_expr.
> >>
> >> Interested in tackling that improvement, obviously as an independen
> >> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> >> (working copy)
> >> --- gcc/tree-ssa-loop-niter.c (working copy)
> >> +++ gcc/tree-ssa-loop-niter.c (working copy)
> >> @@ -2875,6 +2875,16 @@
> >> low = lower_bound_in_type (type, type);
> >> high = upper_b
Hi,
> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> (working copy)
> --- gcc/tree-ssa-loop-niter.c (working copy)
> +++ gcc/tree-ssa-loop-niter.c (working copy)
> @@ -2875,6 +2875,16 @@
>low = lower_bound_in_type (type, type);
>high = upper_bound_in_type (ty
Hi,
> Consider the following example.
>
> extern unsigned int foo (int*) __attribute__((pure));
> unsigned int
> tr (int array[], int n)
> {
> unsigned int i;
> unsigned int sum = 0;
> for (i = 0; i < n; i++)
> sum += foo (&array[i]);
> return sum;
> }
>
> For 32-bit pointers, the an
Hi,
> > I think a better fix would be to make the nb_iterations_upper_bound
> > semantics
> > consistent with that of nb_iterations. Let me try to do it, hopefully this
> > should
> > be mostly mechanical,
> >
>
> This patch changes the semantics of nb_iterations_upper_bound and
> nb_iteratio
Hi,
> As far as I can tell, what is current calculated in i_bound (and assigned to
> nb_iterations_upper_bound), is the maximum amount of times any statement in
> the
> loop is executed, where any includes exit tests. Differently put, the maximum
> amount of times the loop header is executed.
hm
Hi,
> > The header block of the loop is bb 4, the latch block is bb 3:
> > ...
> > (gdb) p loop.header.index
> > $4 = 4
> > (gdb) p loop.latch.index
> > $5 = 3
> > ...
> >
> > The number of times the latch edge is executed, is 10.
> >
> > But loop->nb_iterations_upper_bound, or max_niter is 11:
Hi,
> The analysis is correct, and the test case needs to be adapted.
>
> I adapted the testcase such that it still replaces the exit test if 'a' is
> declared as 'char a[400]', but not if it is declared as 'extern char a[]'.
>
> ok for trunk?
OK,
Zdenek
Hi,
> > Would it be possible to add the handling of these cases
> > to estimate_numbers_of_iterations, rather than doing it just for ivopts?
>
> Yes, I did that now.
>
> Thanks,
> - Tom
>
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-niter.c (infer_loop_bounds_
Hi,
> On 05/18/2011 11:20 PM, Zdenek Dvorak wrote:
> >> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
> >> + ? shiftadd_cost[speed][mode][m]
> >> + : (mult == op1
> >> +? shiftsub1_cost[speed][mode][m]
> >>
Hi,
> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
> + ? shiftadd_cost[speed][mode][m]
> + : (mult == op1
> +? shiftsub1_cost[speed][mode][m]
> +: shiftsub0_cost[speed][mode][m]));
> + res = new_cost (sa_cost, 0);
> + res = add_costs (res,
Hi,
> Resubmitting with comment.
>
> This improves the estimation of cost of bound calculation:
> - It tries to estimate whether an ssa_name can be used in the loop
> at zero cost, or whether a regcopy is needed to keep the ssa_name
> alive during the loop, and counts the cost of the regcopy.
Hi,
> This patch attemps to estimate the number of iterations of the loop based on
> nonwrapping arithmetic in the loop body.
>
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (struct ivopts_data): Add fields
> max_iterations_p and max_iterations.
>
Hi,
> Resubmitting with comment.
>
> The init cost of an iv will in general not be zero. It will be
> exceptional that the iv register happens to be initialized with the
> proper value at no cost. In general, there will at the very least be a
> regcopy or a const set.
OK. Please add a comment e
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (computation_cost): Prevent cost of 0.
this looks strange. Something like
cost = seq_cost (seq, speed);
if (MEM_P (rslt))
the current code;
else
cost += rtx_cost (rslt, SET, speed));
woul
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost.
OK,
Zdenek
Hi,
> This small fix was inserted to skip DEBUG_INSNs while
> recognizing doloop pattern in loop-doloop.c file. It's a fix
> for the already approved do-loop patch (not in mainline yet,
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) in loop-doloop.c
>
> The patch was tested together
Hi,
when accumulator transformation is performed on a function like
foo(a)
{
if (a > 0)
return 1 + foo (a - 1)
return bla();
}
this becomes
foo(a)
{
int tmp = 0;
while (a > 0)
tm = 1 + tmp;
return tmp + bla();
}
Before, bla was a tail-call, but after the optimization, it i
Hi,
> I'll try to explain what my intention with the code is, by looking at a
> pre-ivopt level example.
>
> :
> p_5 = p_3(D) + i_4(D);
>
> :
> # p_1 = PHI
> # i_2 = PHI
> *p_1 = 0;
> p_6 = p_1 + 1;
> i_7 = i_2 + 1;
> if (i_7 < n_8(D))
> goto ;
> else
> goto ;
>
> :
>
Hi,
> > (since the use_uses_inced_iv test is meaningless).
>
> To me it seems use_uses_inced_iv has meaning:
> - it models something: it states whether the comparison is using
> the iv increment result or the iv phi result.
but that has nothing to do with the value of the iv. For instance,
in
Hi,
> >> it is trying to allow for
> >>
> >> do
> >> {
> >> *p = '\0';
> >> i++; /* use_uses_inced_iv == true */
> >> p++; /* use_after_cand_inc == true */
> >> if (!(i < n))
> >> break;
> >> }
> >> while (1);
> >>
> >> and for
> >>
> >> do
> >> {
> >> *p = '\0';
>
Hi,
> >> + /* Determine if the exit test is formulated in terms of the phi or the
> >> + increment of the use iv. */
> >> + use_uses_inced_iv
> >> += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
> >> +
> >> + /* Determine if the exit test is before or after the in
Hi,
> diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
> --- gcc/tree-ssa-loop-ivopts.c(working copy)
> +++ gcc/tree-ssa-loop-ivopts.c(working copy)
> @@ -1194,6 +1300,7 @@ record_use (struct ivopts_data *data, tr
> gimple stmt, enum use_type use_type)
> {
>
Hi,
>/* Whether the loop body includes any function calls. */
>bool body_includes_call;
> +
> + /* Whether the loop body includes any function calls that possibly have
> side
> + effects. */
> + bool body_includes_side_effect_call;
> };
>
> /* An assignment of iv candidates to
61 matches
Mail list logo
