Paolo Bonzini wrote:
a) if anyone propagates a value anywhere, she should check whether the
propagated value is part of a comparison in a COND_EXPR (and
explicitly fold the comparison, if so).
b) in case of a COND_EXPR, fold_ternary (...) in fold-const.c folds
the comparison before doing anyt
Roberto COSTA wrote:
Diego Novillo wrote:
Roberto COSTA wrote on 09/28/06 05:51:
If time allows me, I'd like to try to see what happens if COND_EXPRs
are kept throughout the GIMPLE passes (I confess I'm curious).
Logically, I see them as richer constructs (they carry more
information than
Diego Novillo wrote:
Roberto COSTA wrote on 09/28/06 05:51:
If time allows me, I'd like to try to see what happens if COND_EXPRs are
kept throughout the GIMPLE passes (I confess I'm curious). Logically, I
see them as richer constructs (they carry more information than the
equivalent control-
Roberto COSTA wrote on 09/28/06 05:51:
> If time allows me, I'd like to try to see what happens if COND_EXPRs are
> kept throughout the GIMPLE passes (I confess I'm curious). Logically, I
> see them as richer constructs (they carry more information than the
> equivalent control-flow code), like
On 9/28/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
I understand there may be additional occasions (currently unexploited)
to generated COND_EXPRs, but why precisely do you expect unlowered
COND_EXPRs be potentially harmful?
They inhibit some control flow optimizations such as jump threading.
Paolo Bonzini wrote:
Yes. This is also true for a few other expressions. IIRC, the
gimplifier expands MAX_EXPR into control flow, even though it is legal
gimple.
In fact it did this, but later it was removed from the gimplifier
because it generated worse code.
The usual reason for this
Yes. This is also true for a few other expressions. IIRC, the
gimplifier expands MAX_EXPR into control flow, even though it is legal
gimple.
In fact it did this, but later it was removed from the gimplifier
because it generated worse code.
The usual reason for this type of thing is that
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>> I have a question about the form of COND_EXPR nodes allowed in GIMPLE
>> representation.
>> By looking at what gimplify.c does (more precisely, at functi
Daniel Berlin wrote:
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I have a question about the form of COND_EXPR nodes allowed in GIMPLE
representation.
By looking at what gimplify.c does (more precisely, at function
gimplify_cond_expr (...) ), I understood that GIMPLE only allows
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I have a question about the form of COND_EXPR nodes allowed in GIMPLE
representation.
By looking at what gimplify.c does (more precisely, at function
gimplify_cond_expr (...) ), I understood that GIMPLE only allows a
restricted form of C
However, when compiling with -ftree-vectorize command-line option, there
are cases of COND_EXPR nodes generated and not gimplified (in the sense
of my previous sentence).
An example of this is gcc.dg/tree-ssa/pr23115.c from the testsuite, when
compiled with '-O2 -ftree-vectorize'.
Is it a kn
Hello,
I have a question about the form of COND_EXPR nodes allowed in GIMPLE
representation.
By looking at what gimplify.c does (more precisely, at function
gimplify_cond_expr (...) ), I understood that GIMPLE only allows a
restricted form of COND_EXPR, in which both 'then' and 'else' operands
12 matches
Mail list logo
