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 the
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 the
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));
__builtin_xxx
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 folded
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. */
if
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
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
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 when some already existing irreducible
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 the
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 create
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 of my priority list
Hi,
2012-09-26 Jorn Rennecke joern.renne...@arc.com
* 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.
*
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_father-header ==
Quoting Zdenek Dvorak rakd...@iuuk.mff.cuni.cz:
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?
* basic-block.h (forwarder_block_p_1
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 these things.
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 just imagine
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 really
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 and
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 ivopts
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-latch,
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_PTR
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
anymore.
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';
p++;
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
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 would
be taken
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 all
the
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.c
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 stmt
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 KR C specify?).
I don't think there is a formal specification of KR C, just the (somewhat
informal) book. On topic of pointer arithmetics,
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 KR C specify?).
I don't think there is a formal specification of KR C, just the (somewhat
informal) book. On topic of pointer
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 independent patch?
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 pointer types, we are really
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 (type,
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.
hmm...
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:
this is a bit
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 t...@codesourcery.com
PR target/45098
* tree-ssa-loop-niter.c
Hi,
2011-05-05 Tom de Vries t...@codesourcery.com
PR target/45098
* tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost.
OK,
Zdenek
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
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, mult
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 with
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 is
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 increment of the
+
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';
if (!(i n))
break;
i++; /*
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 uses.
48 matches
Mail list logo
