at least. How urgent is this? FWIW, I've reproduced
the ICE that Zack mentioned, but I haven't investigated it.
Kazu Hirata
gcc.c-torture/execute/mayalias-2.c XFAIL on -O3 -g?
Thanks,
Kazu Hirata
();
calculate_dominance_info (CDI_DOMINATORS);
Notice that we have three assignments to cfg_altered, but the last one
kills the two previous assignments. Should the last one be |=?
Kazu Hirata
arget hooks. The new target hooks would have a REG_OK_STRICT as
an argument. So in the above example, we would simply psas that
argument to the last argument of legitimate_address_p.
Kazu Hirata
ct, the FRV port and possible others have already started
doing this like so:
#ifdef REG_OK_STRICT
#define REG_OK_STRICT_P 1
#else
#define REG_OK_STRICT_P 0
#endif
Kazu Hirata
x27;t a totally crazy idea because the CCP folds
builtins by directly calling fold_builtin, and Diego is planning to
run CCP at several places, even at an early stage of tree SSA
optimizations. (Currently, we depend on DOM to propagate constants,
but it doesn't fold builtins IIRC.)
Thoughts?
Kazu Hirata
are more than
welcome. Suggestions like "Here is what I would do" would be fine,
too.
Kazu Hirata
diff -u fold-const.c fold-const.c
--- fold-const.c6 Mar 2005 00:44:01 -
+++ fold-const.c6 Mar 2005 00:45:38 -
@@ -6802,6 +6802,7 @@
{
Hi,
> I might need help on others. I'll try to go through these "KAZU" one
> by one, but if you could volunteer to fix one, you are more than
> welcome. Suggestions like "Here is what I would do" would be fine,
> too.
Roger kindly suggested what to do for each of these on IRC.
Kazu Hirata
handling of CALL_EXPR in
fold_ternary. Since ternary expressions are not as common as binary
expressions, I don't except much difference even after we start using
fold_build3.
Kazu Hirata
it harder to revert any of parts 1 through 15.
On the other hand, after applying parts 16 and 17, it's trivial to
make fold_build[12] available although fold_build3 will take some
time, and it would be a bit awkward to provide fold_build[12] but not
fold_build3.
Thoughts?
Kazu Hirata
o generate predicates.md. Of course, you can
replace h8300 with any port with PREDICATE_CODES. My scripts are not
robust, so don't blame me if they eat your files.
I might actually start posting patches to convert to predicate.md.
Kazu Hirata
conv_predicate_codes.tar.gz
Description: Binary data
-patches/2005-03/msg02033.html
ip2k
PR 20582: libgcc build fails despite some interests, such as
http://gcc.gnu.org/ml/gcc/2004-06/msg01128.html
ns32k
-
The same justification as
http://gcc.gnu.org/ml/gcc/2004-06/msg01113.html
Nobody showed an interest in keeping this port.
Kazu Hirata
/gcc.gnu.org/ml/gcc-patches/2005-03/msg02038.html
Roger Sayle requested to keep the call to get_callee_fndecl so that we
can "fold" the first operand of a CALL_EXPR to a FUNCTION_DECL.
FYI, the above FIXME comes from
http://gcc.gnu.org/ml/java-patches/2004-q2/msg00083.html
Kazu Hirata
and the 3.4 branch and continue work in the FSF domain. What
> would be the best way to go about this ?
Send patches to [EMAIL PROTECTED] If you are familiar with ARC
and willing to continue to work on the port, you may want to become a
maintainer. That will speed up the process of merging your work into
the FSF tree.
Kazu Hirata
nd
does not expose to the middle for the purpose of constant propagation.
After all, all we need in get_callee_fndecl seems to be
addr = TREE_OPERAND (call_expr, 0);
return ((TREE_CODE (addr) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL)
? TREE_OPERAND (addr, 0) : NULL_TREE;
Thoughts?
Kazu Hirata
o call it
during inlining?
Kazu Hirata
e are equivalent to simplify_{unary,binary,ternary}. They return
a folded tree if folding is possible. Otherwise, they return
NULL_TREE. If need arises, I am happy to export them for you.
Kazu Hirata
hanks for the information. Does OBJ_TYPE_REF_EXPR only apply to a
CALL_EXPR? In other words, are there other forms of constants that
are exposed by looking into OBJ_TYPE_REF_EXPR?
Kazu Hirata
one thing we
have not implemented in our propagation engine is to process the CFG
worklist in the DFS order of a dominator tree. I haven't looked
closely at this, but if the speed of propagation is a concern, we
should come back to this.
Kazu Hirata
sses of opportunities that my pass misses but DOM
catches, but I'll mention them in a separate message.
> ISTR either stevenb or dberlin implementing a dom-order
> propagation. I think they got a minor speedup that could be
> worth having.
Huh, whey I talked to them on IRC they d
different alias set numbers or do
> we need a conversion from the const to the non-const version?
Yes, they are blocked by may_propagate_copy. Seems to be const
v.s. non-const pointer issue. I haven't come up with a brakedown of
reasons why copies are blocked.
Kazu Hirata
= D.18001_101->head_;
> D.18001_12 = ASSERT_EXPR ;
where we are asserting a copy of D.18001_198, and D.18001_198 itself
may also be used later.
Kazu Hirata
y be able to clean up a few other things
for 4.1 (if every port builds at least).
Mark, it's still April 5, so we could wait for a week and add a couple
of lines to config.gcc in time for 4.0, but if you think this is too
pushy or could distract the 4.0 effort, I am happy to postpone this
until 4.0.1 or 4.1.
Kazu Hirata
hold off.
sparc
Eric Botcazou says he is working on predicates.md himself.
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01694.html
Kazu Hirata
m. What is the status of the patch?
Is there more work or refinement needed?
Kazu Hirata
eration of DOM.
o Take advantage of value ranges in thread_across_edge.
Kazu Hirata
Hi Nathan,
Now that you've checked in your new VEC API, I think that's strictly
more powerful than VARRAY. Should we start converting uses of VARRAY
to VEC? I'd be happy to help out here.
Kazu Hirata
ys to get to this ICE. set_value_range is
used in many places in tree-vrp.c. I'll try to take a look at these
in the next few days.
Kazu Hirata
do
not have a flat structure.
o We can probably remove get_stmt_ann and replace all uses of
stmt_ann. No more lazy stmt_ann allocation.
Thoughts?
Kazu Hirata
t_ann to see where people are
using stmt_ann while a statement is not linked to a basic block.
Kazu Hirata
anest
thing to do. Eventually, I want to completely hide
creation/destruction of stmt_ann from applications (or optimizers if
you like) of the infrastructure.
If this standalone stmt_ann does end up in the instruction stream, we
could structure-copy stmt_ann for the time being (yuck!).
Kazu Hirata
. Once these uses
of stmt_ann are fixed, we can arrange things so that we *CANNOT
POSSIBLY* create stmt_ann and operands (except maybe in
create_ssa_artficial_load). Then the actual work of embedding
stmt_ann into tree_statement_list_node shouldn't be difficult.
Kazu Hirata
m not planning to change the members of
stmt_ann, so hopefully my work won't interfere with yours, but if it
does, please let me know.
Kazu Hirata
Hi Zdenek,
> Once this is done, I would like to start working on moving gimple out of
> trees to the "flat" structure.
Very cool! I am glad you'll be working on this!
Kazu Hirata
t; diffs not applying all over the place like they did with
> get_stmt_operands() being removed.
OK. Meanwhile I'll sit here quietly, collecting information like
which places do weird things with stmt_ann and thinking about how to
go about the transition.
Kazu Hirata
ecessary adjustments.
2. Provide stmt_ann_from_bsi(), a function that gives you stmt_ann
given bsi.
3. Let everybody use stmt_ann_from_bsi(), replace stmt_ann(), and
remove the stmt_ann_t pointer from the stmt node (if these are
possible at all).
4. Hand off to Zdenek for his flat statement project.
I hope this message clarifies things.
Kazu Hirata
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 these tree
annotations already have a field for annotation type, it's more like
appending tree_statement_list_node to stmt_ann_d.)
Kazu Hirata
tements. */
> tree_ann_t ann; /* For everything else. */
> }
Err, I don't see how to tell the garbage collector about this without
a type field. We cannot rely on TREE_CODE (stmt) because CALL_EXPR
may appear by itself or as an rhs of MODIFY_EXPR.
Kazu Hirata
namely ivtmp.195_53 and ivtmp.198_7. My guess is
that a bunch of * and & are confusing the optimizers, but that's just
my guess.
Can we somehow have the best of the two worlds? I want to use the
container field (as in the last illustration), but I also want to use
VEC_iterate.
Note that the second case above speeds up GCC by 0.5% or so.
Kazu Hirata
know that &x->a is nonnull is x is nonnull. (PR21294)
I'll start with a low hanging fruit.
Kazu Hirata
.)
I created an array with more than one thousand elements. I still did
not see a RANGE_EXPR in the array's CONSTRUCTOR. How do I get a
RANGE_EXPR in a CONSTRUCTOR?
Kazu Hirata
Rs get generated during processing of an array's
> initializer -- very early on in the C++ FE.
Do you know how to trigger a RANGE_EXPR? I see that in
build_zero_init, so I tried a big array with only zeros in it, but
that didn't help.
Kazu Hirata
e contents of a
"completely static" array ends up in the .data section, not the
.rodata. It turned out to be a regression from 3.x.
Kazu Hirata
are implicitly
represented by the CFG. I don't think the if-conv is trying to handle
computed gotos here.
By the way, this problem has been filed as PR 18472.
Kazu Hirata
Hi Devang,
> Just remove handling of GOTO_EXPR here and in if_convertible_stmt_p().
OK. Will submit a patch.
Kazu Hirata
ts, but the
document doesn't explicitly forbid tail call optimization for Thumb.
Thanks in advance,
Kazu Hirata
lem is that libssp/configure contains a link test, but we may
not have crt0.o built yet (assuming targets like h8300-elf,
arm-none-eabi, etc).
Is there anyway we could stop configuring libssp in this kind of case?
Or somehow work around the link test? FWIW, I am sitting on the
attac
ven insn matches because we would have to go
through a machine description to find the first matching insn. (By
the way, I do understand that it's OK to have multiple patterns for
different targets because values of TARGET_xxx don't change within one
run of cc1.)
FWIW, the second define_insn above could have "plus" in
operands[1], in which case it overlaps with other insns with plus.
Thanks in advance,
Kazu Hirata
mechanical way, so loose things like this
might have gone unnoticed.
Kazu Hirata
/gcc-svn/trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
I just fixed these.
Kazu Hirata
, but that means we are changing the test case. Shall
we add something like gcc.dg/vect/fwrapv-vect-11.c, remove vect-11.c,
and file a missed optimization PR for vect-11.c?
Any thoughts?
Kazu Hirata
64 so you don't see the failure there.
Oops, I now see what's going on. In this case, I think we can just XFAIL
gcc.dg/tree-ssa/gen-vect-11.c.
Kazu Hirata
Hi Daniel and Diego,
Several months ago, you mentioned that the alias analysis in gcc would
be overhauled. Has this happened yet? If not, I am thinking about
working on alias.c and tree-ssa-alias.c as there are only a handful of
VARRAY uses left.
Thanks,
Kazu Hirata
ching from VARRAY to VEC
will probably not affect my work, so go ahead. I guess that's what you
have in mind? Switching VARRAY to VEC?
Yes, thanks!
Kazu Hirata
ither remove
the line or convert it to VEC somehow.
Thanks,
Kazu Hirata
ed char uc;
} vec_uchar;
DEF_VEC_O(vec_uchar);
DEF_VEC_ALLOC_O(vec_uchar,gc);
But this is more complicated than it should be. If the VEC API does
not support an integer array in GC, what should I do to add that?
Some sketch would be greatly appreciated.
Thanks,
Kazu Hirata
there be two consecutive insns that use cc0 after cc0 is set? (I
don't think so. I think there should be one-to-one correspondence
between cc0 setters and cc0 users, but I've never seen a rule written
somewhere.)
Thanks,
Kazu Hirata
ant to be an optimization or
something that's required for language conformance? If the latter is
the case, can we somehow force a conversion?
Thanks,
Kazu Hirata
ice that TREE_VALUE (link) is part of the loop condition.
Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that
mean? My guess is that soneone was trying to be cautious about
encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should
be using gcc_assert instead.)
E
(TYPE_ARG_TYPES (...)) is NULL. I'll keep putting gcc_assert to see what happens.
Kazu Hirata
this bit elsewhere.
The TREE_VEC node doesn't really have space for per-parameter data
other than the vector proper. I could use TREE_TYPE of TREE_VEC to
keep an array of boolean values to represent ARG_FINAL_P for each
parameter, but I am not sure if that is a clean solution.
Thoughts?
Kazu Hirata
INAL_P is actually
no longer used. It hasn't been deleted yet but it won't ever run.
I'm hoping to merge this to trunk after 4.2 branches ... will that
help?
Yes, that definitely helps.
Thanks,
Kazu Hirata
we'll have to regroup after ECJ goes in.
OK.
Kazu Hirata
&& args != void_list_node && parms == void_list_node)
return 1;
Note again that "args" is compared to void_list_node.
Even more confusing is:
arg = TREE_VALUE (args);
:
:
if (!TYPE_P (arg))
Can a function argument be a type?
Clarification would be greatly apprecaited.
Thanks,
Kazu Hirata
lanning to fix this in future.)
So, Sandra's CALL_EXPEs stuff may be ready for merge, but my TYPE_ARG_TYPE stuff
has a somewhat long way to go.
Thanks,
Kazu Hirata
ace before making the big
conversion.
By the way, the past proposals from Roger Sayle are found at:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01514.html
http://gcc.gnu.org/ml/gcc/2004-01/msg00560.html
Both of these are along the same lines as above.
Any comments?
Kazu Hirata
o
the case where the SSA_NAME is used only once. In other
situations, we might want to have a more relaxed hook although I
cannot come up with a specific example.
Kazu Hirata
transformations include
TRUTH_{AND,OR}IF_EXPR, a lot of COND_EXPR manipulations, etc. If
these are good transformations, we need to move them to the SSA
optimizers as you mentioned..
Kazu Hirata
h a basic block, we can walk the bitmap and
reinitialize those that are used. Again, a good optimizer should be
able to eliminate most of these bit sets, but a non-pure/const
function call will block the cleanup opportunities. Of course, this
bitmap walk is far more expensive than cse_reg_info_timestamp++.
Kazu Hirata
gt; bitmap walk is far more expensive than cse_reg_info_timestamp++.
I just tried this. It comes very close to the current timestamp
approach but loses by 0.3% or so in compile time. I'm attaching a
patch for completeness.
Kazu Hirata
Index: cse.c
70 matches
Mail list logo
