Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following motivations:
1) One of the goals of the pro
Hello,
> On 10/23/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> >Hello,
> >
> >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> >introducing a tree LOOP_HEADER with single argument N (number of
> >iterations of the loop), that wou
Hello,
> >> > quite a lot at the moment). To keep the information valid, we need
> >> > to prevent optimizations from destroying it (e.g., if the number
> >> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> >> > DCE to remove it); this is easy to achieve if n_1 would
Hello,
> >> You are proposing to complete the ssa representation such that
> >> foreach_ssa_uses also iterates over the niter information (a bit like vrp
> >> modifies the ssa chains with its extra assert information). Wouldn't it
> >> be possible to not insert this niter information in the repre
Hello,
at the moment, RTL level loop optimizers and most of the tree-level loop
optimizers do not have assigned specific maintainers. I think this
clearly starts to become a significant problem -- many of the
loop-optimizer related patches in 4.2 timeframe remained unreviewed (the
vectorizer impr
Hello,
> >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> >introducing a tree LOOP_HEADER with single argument N (number of
> >iterations of the loop), that would be present in IL at the beginning of
> >header of each loop. I have following motivations:
> >
> >1) One of th
Hello,
> > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> > > introducing a tree LOOP_HEADER with single argument N (number of
> > > iterations of the loop), that would be present in IL at the beginning of
> > > header of each loop. I have following motivations:
> > >
>
Hello,
> >So, the passes that maniuplate loop structure need to know about
> >LOOP_HEADER and others do not need to worry about LOOP_HEADER.
>
> More acurately, the passes that manipulate the cfg. Right now most of
> these passes don't even know they modify the loop structure.
>
> >Now, focusing
Hello,
> On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> >
> >So you would mark n_1 with TREE_USED, and never let it be removed?
> >What would happen if e.g. the entire loop turns out to be dead code?
> >Or if the loop is rewritten (e.g. vectorized) in a way that changes
> >the number of
Hello,
> On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote:
> > > > However, various optimizer needs to know about this special tree node.
> > >
> > > not really (not any more than they know about other tree codes that are
> > > not interesting for them).
> >
> > If we take an example of Jump
Hello,
> On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote:
>
> > actually, that will be trivial once jump threading updates loop properly
> > (I have a patch for that).
> I'd like to see that.
>
> I recall poking at having threading update things like loop
Hello,
> I am a M.E.Computer science student and doing project on induction variable
> optimization.
>
> Therefore i am reading the file tree-ssa-loop-ivopts.c of gcc-4.0.2 to know
> about what have implemented in that.
>
> Is there any other way to know about what have implemented yet and in
> g
Hello,
> I am pleased to announce that the GCC Steering Committee has
> appointed Zdenek Dvorak and Daniel Berlin as non-algorithmic maintainers
> of the RTL and Tree loop optimizer infrastructure in GCC.
thank you. What exactly does "non-algorithmic" mean in th
Hello,
> I am pleased to announce that the GCC Steering Committee has
> appointed Zdenek Dvorak and Daniel Berlin as non-algorithmic maintainers
> of the RTL and Tree loop optimizer infrastructure in GCC.
>
> Please join me in congratulating Zdenek and Daniel on t
Hello,
> I'm running into some troubles with an if-conversion pass that runs
> after reload, where we have to avoid lifting insns across a loop
> exit edge into a loop. ifcvt.c uses flow_loops_find to find loops
> and mark all loop exit edges:
>
> if ((! targetm.cannot_modify_jumps_p ())
>
Hello,
> >Now, if your argument is that following the LIA-1 standard will prevent
> >optimizations that could otherwise be made if one followed only the C
> >standard, that's a reasonable argument, but it should not be couched as
> >if it implies that preventing the optimizations would not be f
Hello,
> > Paul Brook wrote:
> > >> Compiler can optimize it any way it wants,
> > >> as long as result is the same as unoptimized one.
> > >
> > > We have an option for that. It's called -O0.
> > >
> > > Pretty much all optimization will change the behavior of your program.
> >
> > Now that's
Hello,
> > > > The situation is that some SSA_NAMEs are disused (removed from the
> > > > code) without being released onto the free list by
> > > > release_ssa_name().
> > > >
> > > Yes, it happens if a name is put into the set of names to be updated by
> > > update_ssa.
> > >
> > > After update_
Hello,
> On Thu, 2006-12-21 at 20:18 +0100, Zdenek Dvorak wrote:
>
> > I think this might be a good idea. I think that this requires
> > a lot of changes (basically going through all uses of bsi_remove
> > and remove_phi_node and checking them), but it would be clea
Hello,
> > > I think this might be a good idea. I think that this requires
> > > a lot of changes (basically going through all uses of bsi_remove
> > > and remove_phi_node and checking them), but it would be cleaner
> > > than the current situation.
> > Agreed. Tedious work, but it shouldn't be
Hello,
> >I have been looking into infer_loop_bounds_from_signedness() called
> >from infer_loop_bounds_from_undefined().
> >At some places, nowrap_type_p() is used but this function operates
> >only on types, so there will be too many false positive there; yet we
> >will miss warning through that
Hello,
> > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and
> > higher optimization level at x86_64-redhat-linux.
> >
> > reload1.c: In function 'reload':
> > reload1.c:449: error: address taken, but ADDRESSABLE bit not set
> > bad_spill_regs
> >
> > reload1.c:449: error: a
Hello,
> > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and
> > > higher optimization level at x86_64-redhat-linux.
> > >
> > > reload1.c: In function 'reload':
> > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set
> > > bad_spill_regs
> > >
> > > reload1
Hello,
with the changes to the build system in the last few months, I am having
problems to do some things I am used to do during development. I found
more or less satisfactory procedures for most them, however, I would
like to know the "official" way how to achieve those effects (and to put
the
Hello,
thanks a lot for the answers!
> >Q4) How to compile all the libraries (libjava, ...) using the stage1
> >compiler?
>
> A4) Configure with --enable-stage1-languages=all
Is there a way how to do it without reconfiguring gcc? This question
aims at the following situation: I already hav
Hello,
> >Is there a way how to do it without reconfiguring gcc?
>
> No. Do you think it would be best to have --enable-stage1-languages=all
> in non-release branches? The time taken to compile the stage1
> (nonoptimized) non-C front-ends is small, and the advantage seems
> significant.
if
Hello,
> >> One idea I've always pondered is to have brief (perhaps 1-2 hr)
> >> tutorials, given by people in their area of expertise, as a means for
> >> other developers to come up to speed on a topic that interests them. Is
> >> this something that appeals to others?
> >>
> >Sounds good to me
Hello,
> I've changed gcc by adding a new pass, however, when I compile gcc,
> during compilation it calls itself, so I disabled bootstrap but that
> is still happening even during bootstrap. Is there any way to compile
> gcc without the final gcc compiling something?
make stage1-bubble. See als
Hello,
> >As we also only vectorize innermost loops I believe doing a
> >complete unrolling pass early will help in general (I pushed
> >for this some time ago).
> >
> >Thoughts?
>
> It might also hurt, though, since we don't have a basic block
> vectorizer. IIUC the vectorizer is able to turn
Hello,
> Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
>
> > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> >
> > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> > >
> ...
> > >
> > > That's going to change once this project goes in: "(3.2) Straight-
> > > line
Hello,
> "Linthicum, Tony" <[EMAIL PROTECTED]> writes:
>
> > * Would using a tree-level API like estimate_num_insns be superior
> > to using a simple cost of 1 per statment?
>
> For this sort of calculation, I would guess not. I would imagine that
> on most processors the cost of a single
Hello,
> For instance, let's consider the following struct definition (taken from
> gcc.dg/struct-alias-1.c):
>
> struct S {
>int a[3];
>int x;
> };
>
> This is the original code in GIMPLE pseudo-C dump representation:
>
> s.x = 0;
> i.0 = i;
> s.a[i.0] = 1;
> D.1416 = s.x;
>
Hello,
> >you might try turning the references to TARGET_MEM_REFs, and copy the
> >alias information using copy_ref_info to it. I am not sure how that
> >would interact with the transformations you want to do, but we do lot
> >of magic to keep the virtual operands for TARGET_MEM_REFs the same
> >
Hello,
> >>>you might try turning the references to TARGET_MEM_REFs, and copy the
> >>>alias information using copy_ref_info to it. I am not sure how that
> >>>would interact with the transformations you want to do, but we do lot
> >>>of magic to keep the virtual operands for TARGET_MEM_REFs the
Hello,
> >>In principle, I don't see anything forbidding Zdenek's idea.
> >>Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
> >>are also transformed into pointer arithmetics
> >>and the equivalent
> >>INDIRECT_REF memory access... therefore, this is not an option even only
Hello,
> >this seems quite close to what TARGET_MEM_REFs are designed for. IMHO,
> >the best way would be to lower the memory references to TARGET_MEM_REFs
> >(*) just once, sometime quite late in the optimization pipeline (just after
> >loop optimizations, for example), so that high-level optimi
Hello,
> I've been trying to keep the GCC_4.3_Release_Planning wiki page up to
> date, and I'd like to be sure I haven't missed anything going in. I've
> moved several projects to the Completed section, and if I've done
> anything in error there, please correct it.
>
> So here's a survey of what'
Hello,
> I noticed that gcc.dg/tree-ssa/loop-19.c was failing on both
> powerpc-linux-gnu and powerpc64-linux-gnu:
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol:
> )a, 2
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol:
> )c, 2
>
> The reas
Hello,
> > only gimple_vals (name or invariant). However, the expressions are
> >matched in final_cleanup dump (after out-of-ssa and ter), so this no
> >longer is the case. I think just the regular expressions need to be
> >updated.
>
> Then IV-OPTs has an issue too but IV-OPTs dump gives:
> D
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple. For example, there are about 1000 of
lines of quite
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
Hello,
> >> This looks like a very complicated (though very generic) way of
> >> specifying a memory
> >> reference. Last time we discussed this I proposed to just have BASE,
> >OFFSET
> >> and accessed TYPE (and an alias tag of the memory reference). I realize
> >> this
> >> doesn't cover acce
Hello,
> >Proposal:
> >
> >For each memory reference, we remember the following information:
> >
> >-- base of the reference
> >-- constant offset
> >-- vector of indices
> >-- type of the accessed location
> >-- original tree of the memory reference (or another summary of the
> > structure o
Hello,
> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also keeping it in the references.
> >
> >The lower bound and
Hello,
> > -- base of the reference
> > -- constant offset
> > -- vector of indices
> > -- type of the accessed location
> > -- original tree of the memory reference (or another summary of the
> > structure of the access, for aliasing purposes)
> > -- flags
>
> What do you do with Ada COMPO
Hello,
> >at the moment, any pass that needs to process memory references are
> >complicated (or restricted to handling just a limited set of cases) by
> >the need to interpret the quite complex representation of memory
> >references that we have in gimple. For example, there are about 1000 of
>
Hello,
> >> >> That is, unless we could share most of the index struct (upper,
> >> >> lower, step) among expressions that access them (IE make index be
> >> >> immutable, and require unsharing and resharing if you want to modify
> >> >> the expression).
> >> >
> >> >That appears a bit dangerous
Hello,
> >Remarks:
> >-- it would be guaranteed that the indices of each memory reference are
> > independent, i.e., that &ref[idx1][idx2] == &ref[idx1'][idx2'] only
> > if idx1 == idx1' and idx2 = idx2'; this is important for dependency
> > analysis (and for this reason we also need to reme
Hello,
> 2. Right now I am inserting a __builting_prefetch(...) call immediately
> before the actual read, getting something like:
> D.1117_12 = &A[D.1101_14];
> __builtin_prefetch (D.1117_12, 0, 1);
> D.1102_16 = A[D.1101_14];
>
> However, if I enable the instruction scheduler pass, it doesn
Hello,
> Well, the target architecture is actually quite peculiar, it's a
> parallel SPMD machine. The only similarity with MIPS is the ISA. The
> latency I'm trying to hide is somewhere around 24 cycles, but because it
> is a parallel machine, up to 1024 threads have to stall for 24 cycles in
Hello,
> Steve Ellcey wrote:
>
> >This seems unfortunate. I was hoping I might be able to turn on loop
> >unrolling for IA64 at -O2 to improve performance. I have only started
> >looking into this idea but it seems to help performance quite a bit,
> >though it is also increasing size quite a bi
> Look from what we're starting:
>
> <<
> @item -funroll-loops
> @opindex funroll-loops
> Unroll loops whose number of iterations can be determined at compile
> time or upon entry to the loop. @option{-funroll-loops} implies
> @option{-frerun-cse-after-loop}. This option makes code larger,
> and
Hello,
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > On 4/22/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > > but also does not make anyone actually use the options. Nobody reads
> > > > > the documention. Of course, this is a bit overstatement, but with a
> > > > > few
Hello,
> 4. PR 31360: Missed optimization
>
> I don't generally mark missed optimization bugs as P1, but not hoisting
> loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this
> on mainline. Andrew says that patch has a bug. So, what's the story here?
I found the problem, I wi
Hello,
> (based on gcc 4.1.1).
now that is a problem; things have changed a lot since then, so I am not
sure how much I will be able to help.
> 1. The problem was unveiled by compiling a testcase with dump turned
> on. The compilation failed while calling function get_loop_body from
> flow_loop_
Hello,
> >Although you have listed it as "stage 2", I wish to commit the finished
> >portion as soon as possible during stage 1. I have maintainership
> >authority
> >to do so. This will not interfere in any way with *any* of the projects
> >approved for stage 1, since it is in a disjoint secti
Hello,
> >>>>> Zdenek Dvorak writes:
>
> Zdenek> I must admit I have very bad feeling about the whole "4.1 Projects"
> Zdenek> stuff. IMHO this over-organizes things. If people in general
> disagree
> Zdenek> with the Nathan's changes,
Hello,
> (This time around, the there seemed to be consensus that all proposals
> be made public upon submission. Since that seems to be the consensus,
> I'll implement that in the next release cycle.)
yes, this would definitely make sense.
Zdenek
Hello,
> >at the beginning of the stage 1, there always is lot of major changes
> >queued up. It never lead to unmanageable amount of "breakage and
> >disruption".
>
> Other people have a different perception than you do.
>
> >As for constructive suggestions -- why not just forget on whole plan
Hello,
> Giv optimizations are just features which not
> implemented yet in the new loop unroller, so I think
> put it in bugzilla is not appropriate.
it most definitely is appropriate. This is a performance
regression. Even if it would not be, feature requests
can be put to Bugzilla.
The be
Hello,
> Why is D.1476 not being propagated? IVOPTS introduces it,
> but I don't see any reason why...
>
> Also, why all the leading zeros? Is there something special
> about that constant? The initial RTL gcc produces for the
> assignment to D.1476 is also suboptimal:
>
> ;; D.1476 = -00
Hello,
> >I think I will try the later fix today (mostly because I no longer
> >remember what exactly were the problems that lead me to introducing
> >the TREE_OVERFLOW check to is_gimple_min_invariant).
>
> http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00786.html
> And yes the testcase still fail
Hello,
> Which appears to walk down the array and try and choose better IV sets.
> Since it walks down the IV array, which is in SSA_NAME_VERSION order.
> Thus two loops which are equivalent in all ways except that they use
> different SSA_NAME_VERSIONs can get different IV sets.
>
> Anyway, the
Hello,
> VIEW_CONVERT_EXPR is tcc_reference, but we can have a statement like:
>
> x = 22;
what is the semantics of this expression? Should not this rather be
x = 22
(or just INTEGER_CST:some_type 22)?
Zdenek
> What ends up happening here is that find_interesting_uses_stmt calls
> f
Hello,
> > x = 22;
>
> what is the semantics of this expression? Should not this rather be
>
> x = 22
>
> (or just INTEGER_CST:some_type 22)?
>
> Depends what the type is. If it's an array type, then there's no
> simple equivalent expression.
using CONSTRUCTOR n
Hello,
> > Depends what the type is. If it's an array type, then there's no
> > simple equivalent expression.
>
> using CONSTRUCTOR node?
>
> What I mean by "simple" is something that's easy to derive. Suppose I have
> a record with numerous fields of various sizes and I unchecked
Hello,
> On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > The last ChangeLog of rtlopt-branch was written in
> > 2003. After more than one year, many impovements in
> > this branch haven't been put into the GCC HEAD. Why?
>
> Almost all of the rtlopt branch was merged. Prefetching is one
>
Hello,
> On Sunday 27 March 2005 04:45, Canqun Yang wrote:
> > Another question is why the new RTL loop-unroller does
> > not support giv splitting.
>
> Apparently because for most people it is not a problem that it does
> not do it, and while you have indicated earlier that it may be useful
> fo
Hello,
> > Steven Bosscher <[EMAIL PROTECTED]>:
> >
> > >
> > > What happens if you use the memory address unrolling
> > patch, turn on
> > > -fweb, and set the unrolling parameters properly?
> > >
> >
> > The memory address unrolling patch can't work on IA-
> > 64,
>
> Ah, no base+offset. It
Hello,
> I am thinking about merging stmt_ann_d into tree_statement_list_node.
>
> Background
> --
>
> tree_statement_list_node is a linked list node defined like so
>
> struct tree_statement_list_node {
> struct tree_statement_list_node *prev;
> struct tree_statement_list_node *next
Hello,
> > o One step closer to a flat statement structure (or a tuple form if
> > you like). It's a bit silly that we have GIMPLE, but we still do
> > not have a flat structure.
on a side note, I am currently working on cleaning up gimplification
(mostly to enable embedding of simple and fa
Hello,
> > Then why not simply shorten this to:
> >
> > 1) put stmt annoation directly in the tree_statement_list_node
> >
> > 2) replace stmt_ann_t pointer in stmt with a pointer to its BSI, or the
> > tree_statement_list_node. This makes bsi_from_stmt O(1) immediately.
> >
> > 3) all stmts n
Hello,
> > > This looks like a better approach. How would we do your step 1? We
> > > have var_ann and tree_ann in addition to stmt_ann. Shall we put a
> > > type field at the beginning of tree_statement_list_node+stmt_ann_d so
> > > that an annotation node can identify itself? (Since all thes
Hello,
> I cannot see how fold-const.c:try_move_mult_to_index ever
> successfully will do a transformation if the loop
>
> for (;; ref = TREE_OPERAND (ref, 0))
> {
> if (TREE_CODE (ref) == ARRAY_REF)
> {
> ...
> break;
> }
>
> if (!handled_component_p
Hello,
> >To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a
> >simple dummy function.
>
> Kazu, I hope I have time to look in detail at your investigation, however
> one thing that might be causing a problem is that FOR_EACH_EDGE is an
> iterator
> that works for a non-constant
Hello,
I am just playing with loop unrolling on trees (for the purposes of
prefetching), and I encountered the following problem. Consider loop
sum1 = 0;
sum2 = 0;
for (i = 0; i < n; i++)
{
x_1 = a[i];
y_1 = b[i];
sum1 += x_1 * y_1;
sum2 += x_1 / y_1;
}
Now after unrolling w
Hello,
> > > So far OK, but with ter, this becomes
> > >
> > > sum1 = 0;
> > > sum2 = 0;
> > > for (i = 0; i < n; i+=4)
> > > {
> > > x_1 = a[i];
> > > y_1 = b[i];
> > > x_2 = a[i+1];
> > > y_2 = b[i+1];
> > > x_3 = a[i+2];
> > > y_3 = b[i+2];
> > > x_4 = a[i+3];
> >
Hello,
> Don't know how to fix this - nothing obvious. But we create at
>
> *op = build1 (INDIRECT_REF, TREE_TYPE (*op), with);
>
> an INDRECT_REF of the form
>
> type size
> unit size
> align 8 symtab 1075593216 alias set -1 precision 8 min
> max
>
Hello,
> On Wednesday 08 June 2005 12:01, Nick Burrett wrote:
> > $ ./cc1 -quiet test.c -mthumb -O2
> > ../../bug.c: In function ?foo?:
> > ../../bug.c:3: internal compiler error: in create_mem_ref, at
> > tree-ssa-address.c:585
> > Please submit a full bug report,
>
Hello,
I have run into the following problem:
recompute_tree_invarant_for_addr_expr says that address of a decl
is invariant if it is a decl in the current function:
if (decl_function_context (node) == current_function_decl)
... /* set TREE_INVARIANT */
This has a small flaw -- in case NODE
Hello,
> On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> > This has a small flaw -- in case NODE has variable size, it gets
> > allocated on stack dynamically, it may be allocated and deallocated
> > several times, and its address is no longer an invariant.
&
Hello,
> On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> > This has a small flaw -- in case NODE has variable size, it gets
> > allocated on stack dynamically, it may be allocated and deallocated
> > several times, and its address is no longer an invariant.
&
Hello,
> On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote:
> > OK, I remembered. I put
> >
> > if (is_gimple_min_invariant (t))
> >
> > or
> >
> > if (is_gimple_val (t))
> > {
> > shortcut;
> > }
> >
&
Hello,
> I've noticed that -floop-optimize2 tends to be a pessimism on many
> algorithms.
>
> I'm hesitant to file this as a "bug", given that -floop-optimize2 is a
> "new" replacement for the older loop optimizer.
>
> Is -floop-optimize2 still in development, and not ready yet -- or are
> the p
Hello,
> I want to use profiling information. I know there're two relevent
> fields in each basic block, count and frequency. I want to use
> frequency because the compiled program is for another architecture so
> it cannot run on the host.
>
> I use -fprofile-arcs.
this does not make much sens
Hello,
> Isn't it the case that *any* conversion can be stripped for the purpose
> of this routine? I get an ICE compiling the Ada RTS a-strfix.adb because
> of that. The following seems to fix it, but is it right?
no, it is not. The uses of constant_multiple_of expect that it
determines wheth
Hello,
> If no one is suggesting an alternative, tested on x86 and x86_64-linux
> where it restores bootstrap (at last :), ok to commit?
I think the patch is fine (although of course I cannot approve it). The
more proper fix would be to never expand such expressions from ivopts;
I have a patch f
Hello,
> I think the patch is fine (although of course I cannot approve it).
>
> I, as it's author, do not. But, as I keep saying, I don't know what
> the proper fix is.
preventing record_block_change from working in this situation seems a
quite clean solution to me; of course, not expand
Hello,
> > The other thing we could try to do is put virtual variables in loop-closed-
> > form, at least just before the vectorizer, and at least just for some
> > loops. Does this sound reasonabale? (By the way, why don't we keep virtual
> > variables in loop-closed-form?)
>
> We used to, nobod
Hello,
> >A more likely source of performance degradation is that loop unrolling
> >is enabled when profiling, and loop unrolling is almost always a bad
> >pessimization on 32 bits x86 targets.
>
> To clarify, I was compiling with -funroll-loops and -fpeel-loops
> enabled in both cases.
>
> The
Hello,
> Dale Johannesen wrote:
> > I think this is a simple pasto; this code was evidently copied from
> > the previous block:
> >
>
> I don't think that this was a simple pasto. The code looks correct.
> We have the same code in tree-ssa-loop-niter.c around line 436, since
> we inherited this
Hello,
> > >you may try adding -fmove-loop-invariants flag, which enables new
> > >invariant motion pass.
> >
> > That cleaned up both my simplified test case, and the code it
> > originated from. It also cleaned up a few other cases where I
> > was noticing worse performance with FDO enabled.
Hello,
I have run into following problem with dom. One of the places
where cfg_altered is set is wrong:
Index: tree-ssa-dom.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-dom.c,v
retrieving revision 2.124.2.1
diff -c -3 -p -r2.124.2.1 tre
Hello,
> > I have run into following problem with dom. One of the places
> > where cfg_altered is set is wrong:
> It's not really wrong, it's set this way on purpose, specifically
> to avoid the compile-time explosion you're seeing.
This works by pure luck only, I think. In fact, the only thing
Hello,
I have the following insn:
(insn 522 521 523 87 (set (reg:SI 308)
(reg:SI 0 ax)) 40 {*movsi_1} (nil)
(insn_list:REG_RETVAL 520 (expr_list:REG_EQUAL (parity:DI (reg:DI 248 [
D.1874 ]))
(nil
Is this correct? I have a piece of code that breaks if mode of the
assi
Hello,
> Can someone please help me getting the following information?
>
> 1) I would like to obtain the loop bounds (constant case) of all nested
> loops
> of a RTL insn. Is there a data structure over which I can iterate to get
> bounds
> for each nested loop of a RTL insn?
>
> 3) Can I deter
Hello,
> As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html
>
> I would like to improve SMS by passing data dependencies information
> computed in tree-level to rtl-level SMS. Currently data-dependency graph
> built for use by SMS has an edge for every two data references (i.e. it'
Hello,
> There don't seem to be many comments explaining why we're doing
> what we're doing here, so I'm not sure whether this was the intended
> behaviour or not. Do we really want to kick out existing DECL_RTLs,
> or is there simply a missing !DECL_RTL_SET_P in the DECL_P condition:
I think th
Hello,
during expansion of expressions, gimplification creates a lot of temporary
variables. VAR_DECLs are fairly large (88 bytes on i686), and
additionally an annotation (44 bytes on i686) are allocated for each of
them (some of them even get names, for additional ~50 bytes of memory
each). Thi
1 - 100 of 228 matches
Mail list logo
