On Thu, 24 Oct 2013, Jakub Jelinek wrote:
> On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> > + FOR_EACH_LOOP (li, loop, 0)
> > +if (loop->latch)
> > + FOR_EACH_EDGE (e, ei, loop->latch->succs)
>
> Isn't the only successor of loop->latch loop->header?
> Thus, can't you
On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> + FOR_EACH_LOOP (li, loop, 0)
> +if (loop->latch)
> + FOR_EACH_EDGE (e, ei, loop->latch->succs)
Isn't the only successor of loop->latch loop->header?
Thus, can't you just remove the above two lines and use loop->header
inst
On Thu, 24 Oct 2013, Tobias Burnus wrote:
> Richard Biener wrote:
> > Please instead amend tree-cfg.c:execute_build_cfg and do after
> > loop_optimizer_init sth like
> > [...]
> > possibly doing after it
> >FOR_EACH_BB (bb)
> > [...]
> > +DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expres
Richard Biener wrote:
Please instead amend tree-cfg.c:execute_build_cfg and do after
loop_optimizer_init sth like
[...]
possibly doing after it
FOR_EACH_BB (bb)
[...]
+DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)
FIXME? Btw, not using a tree operand here is somewhat of a
On Mon, 21 Oct 2013, Tobias Burnus wrote:
> Dear all,
>
> attached is a new version of the patch. Changes:
> * "#pragma GCC ivdep" instead of "#pragma ivdep"
> * Corrections to the error message in c-parser.c and a test case for it
> * New wording in the .texi and examples
>
> I am still not com
On 21 October 2013 22:09, Tobias Burnus wrote:
> attached is a new version of the patch. Changes:
> * "#pragma GCC ivdep" instead of "#pragma ivdep"
> * Corrections to the error message in c-parser.c and a test case for it
> * New wording in the .texi and examples
Not that I have any authority he
On Mon, 21 Oct 2013, Tobias Burnus wrote:
> Dear all,
>
> attached is a new version of the patch. Changes:
> * "#pragma GCC ivdep" instead of "#pragma ivdep"
> * Corrections to the error message in c-parser.c and a test case for it
> * New wording in the .texi and examples
>
> I am still not com
Dear all,
attached is a new version of the patch. Changes:
* "#pragma GCC ivdep" instead of "#pragma ivdep"
* Corrections to the error message in c-parser.c and a test case for it
* New wording in the .texi and examples
I am still not completely happy with the wording – and I am open for
sugges
On Thu, Oct 17, 2013 at 10:07:43AM +0200, Richard Biener wrote:
> Which suggests we use
>
> #pragma GCC ivdep
>
> to not collide with eventually different semantics in existing programs
> that use variants of this pragma?
Yeah, perhaps.
> > Intel:
> > http://software.intel.com/sites/products/d
On Wed, 16 Oct 2013, Tobias Burnus wrote:
> Frederic Riss wrote:
> > Just one question. You describe the pragma in the doco patch as:
> >
> > +This pragma tells the compiler that the immediately following @code{for}
> > +loop can be executed in any loop index order without affecting the result.
>
Frederic Riss wrote:
> Just one question. You describe the pragma in the doco patch as:
>
> +This pragma tells the compiler that the immediately following @code{for}
> +loop can be executed in any loop index order without affecting the result.
> +The pragma aids optimization and in particular vecto
Hi,
Just one question. You describe the pragma in the doco patch as:
+This pragma tells the compiler that the immediately following @code{for}
+loop can be executed in any loop index order without affecting the result.
+The pragma aids optimization and in particular vectorization as the
+compiler
On Thu, 10 Oct 2013, Tobias Burnus wrote:
> Joseph: Could you have a look at the C part? Thanks!
Your error "missing loop condition loop with IVDEP pragma" should, I
think, say "loop condition in loop". Since the pragma is "ivdep"
(case-sensitive), it should also say % not IVDEP. This
restri
Richard: Could you review the Gimple part? Thanks!
Joseph: Could you have a look at the C part? Thanks!
Jakub Jelinek wrote:
+ if (loop->latch)
+ FOR_EACH_EDGE (e, ei, loop->latch->succs)
+ {
+ if (e->dest->flags & BB_RTL)
+ break;
I'd prefer Richard to
On Tue, Oct 08, 2013 at 10:51:29PM +0200, Tobias Burnus wrote:
> + return false;
> + }
> + c_parser_for_statement (parser, true);
> + return false;
> +
> case PRAGMA_GCC_PCH_PREPROCESS:
>c_parser_error (parser, "%<#pragma GCC pch_preprocess%> must be
> first");
>
Jakub Jelinek wrote:
On Tue, Oct 08, 2013 at 08:51:50AM +0200, Tobias Burnus wrote:
+ if (loop->latch && loop->latch->next_bb != EXIT_BLOCK_PTR
+ && bb_seq_addr (loop->latch->next_bb))
Why this bb_seq_addr guard?
Without, I get a segfault in the stage 1 (prev-gcc/xg++) compiler
16 matches
Mail list logo
