This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] tree level if-conversion for vectorizer
On Aug 26, 2004, at 1:56 AM, Richard Henderson wrote:
On Wed, Aug 25, 2004 at 10:53:16PM -0700, Devang Patel wrote:
+ num_uses = num_immediate_uses (df);
+
+ for (j = 0; j < num_uses; j++)
+ {
+ tree use = immediate_use (df, j);
+ if (TREE_CODE (use) == PHI_NODE)
Why are you iterating over the PHI nodes both here for
the modify_expr, and later via the PHI node? Seems to
me the former is sufficient.
Here I check if modify_expr's result is used in PHI node or not. I
check phi arguments. Later I check if PHI_RESULT, which is not
is_gimple_reg() is immediatly used in PHI node or not. Here I check if
virtual phi is immediately used in another phi or not.
+ switch (TREE_CODE (TREE_OPERAND (m_expr, 1)))
+ {
+ case CALL_EXPR:
+ case TRUNC_DIV_EXPR:
+ case INDIRECT_REF:
+ case ARRAY_REF:
This list isn't anywhere near complete. Anyway, I think all
of this should be reducible to tree_could_trap_p.
ok
Well, you
probably don't want to ifcvt a call, even if it is to a pure
function.
+ /* Attempt to do simple boolean expression simplification. */
fold?
Yup, why not?
+ /* Create temporary for C in < A = COND_EXPR < C, B>>. */
+ new_cond = ifc_temp_var (boolean_type_node, unshare_expr (cond),
bsi, true);
A temporary is not required if COND is a simple condition,
a-la is_gimple_condexpr.
Yes. This is why I asked you couple of questions regarding - holding
value of vector compare. I was in late-stage during in my testing of
this patch, so I decided to get feedback for rest of the patch as it
stands.
In practice this means one level
comparison, no conjunction or disjunction.
+ static void
+ handle_sibling_pattern (struct loop *loop)
+ {
+ basic_block *hsp_bbs;
+ basic_block bb;
+ block_stmt_iterator bsi;
+ unsigned int i;
+
+ compute_immediate_uses (TDFA_USE_OPS, NULL);
+ compute_immediate_uses (TDFA_USE_VOPS, NULL);
Why are you traversing forward def->use rather than backward from
use->def?
May be because the way I follow my thought process?
How would you do otherwise?
+ /* FIRST and SECOND statements are sibling statements.
+ If possible fold FIRST statement into SECOND statement
+ and remove FIRST statement.
+
+ 1)
+ T1 = cond ? (void)0 : B;
+ T2 = cond ? A : (void)B;
Err, did I miss something earlier? Are those void's really there?
They certainly should not be.
If basic block B1 is destination when COND is true and B2 is
destination when COND is false then while updating B1 statements
t1 = A;
is converted into
t1 = cond ? A : (void)0;
And B2 statements
t2 = B;
is converted into
t2 = cond ? (void)0 : B;
(this is done in make_cond_modify_expr()).
I suppose that (void)0 is supposed to be from the default statement?
Suppose you do not find a sibling for this conditional, because the
variable really was only partially set in the original. Do you leave
this invalid code hanging about, or do you simplify to "T1 = B"?
What if there is no corresponding sibling in B2?
modify_expr from B1 needs COND. If COND is true, I simplify.
Why would you be checking for default anyway? Isn't
t1 = cond ? a : b
t2 = cond ? t1 : c
->
t2 = cond ? a : c
correct no matter what the values of a/b/c?
+ /* Return TRUE iff, EXP is boolean exp.
+ CHECKME: Move this into tree.c? */
What are you trying to accomplish?
While generating temp, I check if it will need speculative load or not.
Later, I intend to add basic speculative load support. boolean exp does
not need it. hmm.. but you pointed me towards tree_could_trap_p, any
way.
+ /* Return TRUE iff, EXP is constant.
+ CHECKME: Move this into tree.c? */
TREE_CONSTANT?
*blush*
+ /* Return TRUE iff, EXP needs speculative load support.
+ See above for a speculative load example. */
tree_could_trap_p?
ok
*************** build_ssa_operands (tree stmt, stmt_ann_
*************** get_expr_operands (tree stmt, tree *expr
You needed to modify both of these for operand handling?
I find that surprising. The later should have been sufficient.
I do not remember in which order I added them but I added it
at one place and it was also required at the second.
I will double check.
! if (TREE_CODE (TREE_OPERAND (expr, 1)) == COND_EXPR)
And given that this doesn't start with "case COND_EXPR:"
I'll claim you've done it in the wrong place.
It is inside MODIFY_EXPR. In build_ssa_operands, as well as
get_expr_operands, I handle each operands of COND_EXPR separately.
-
Devang