I suppose that there are some bugs in the snapshot gcc-4.1-20070514.
gcc/rtl.h
---------
/* Register Transfer Language EXPRESSIONS CODE CLASSES */
enum rtx_class {
/* We check bit 0-1 of some rtx class codes in the predicates below. */
/* Bit 0 = comparison if 0, arithmetic is 1 #<-wrong! v- bit 0
Bit 1 = 1 if commutative. */ #<-wrong! v- bit 1
RTX_COMPARE, /* 0 */ # 0 = 0 0 0 0
RTX_COMM_COMPARE, # 1 = 0 0 0 1
RTX_BIN_ARITH, # 2 = 0 0 1 0
RTX_COMM_ARITH, # 3 = 0 0 1 1
/* Must follow the four preceding values. */
RTX_UNARY, /* 4 */ # 4 = 0 1 0 0
RTX_EXTRA, # 5 = 0 1 0 1
RTX_MATCH, # 6 = 0 1 1 0
RTX_INSN, # 7 = 0 1 1 1
/* Bit 0 = 1 if constant. */
RTX_OBJ, /* 8 */ # 8 = 1 0 0 0
RTX_CONST_OBJ, # 9 = 1 0 0 1
RTX_TERNARY, # 10= 1 0 1 0
RTX_BITFIELD_OPS, # 11= 1 0 1 1
RTX_AUTOINC # 12= 1 1 0 0
};
#
# BEGIN CORRECTING below will be correct!
#
/* We check bit 0-1 of 4 first rtx class codes in the predicates below.
Bit 0 = 1 if commutative.
Bit 1 = 0 if comparison, 1 if arithmetic. */
#
# END CORRECTING
#
gcc/loop.c
----------
#
# To see who uses loop_invariant_p that doesn't return a boolean,
# returns an int with values 0, 1 and 2.
#
# Be careful with it when you will really assume inside of the action's body
# of IF because it's 1 or 2 (or it's !0), and when wont really because it is
# 0 (or it's !1 and !2).
# It has to distinguish easyly if
# IT REALLY IS :
# =0 : "NOT INVARIANT" OF THE LOOP !!!
# =1 : "INVARIANT INCONDITIONAL" OF THE LOOP !!!
# =2 : "INVARIANT CONDITIONAL" OF THE LOOP !!!
# Some lines put condition ([XXX =] loop_invariant_p) and another lines
# put the equivalent condition (([XXX =] loop_invariant_p) != 0), and
# i don't understand the why of this difference?
# Actually, in the src code, it's confuse.
# a) tem = loop_invariant_p (...)
# What meaning is it when you think in the algorithm?
# * Does it mean that it can be "INVARIANT INCOND." or "INVARIANT COND."?
# * Or, does it mean that it's "INVARIANT INCOND." but not "INVARIANT COND."?
# b) (... && loop_invariant_p (...))
# Does you think that it will be true because (... && true')?
# * Does it mean that it will be true' because it was
# "INVARIANT INCOND."(=1) or "INVARIANT COND."(=2)?
# * Or only "INVARIANT INCOND."(=1) because true' is 1 and
# "INVARIANT COND."(=2) doesn't count?
# c) if (!loop_invariant_p (loop, iv->add_val))
# "! NOT INVARIANT" is true "INVARIANT" because not(not(x))=x, but
# "INVARIANT COND." only or "INVARIANT INCOND." only or either?
# d) (... || ! loop_invariant_p (...) || loop_invariant_p (...))
# I see it a little dangerous. || is applied to bools, but they are ints.
# Is it "|| beetween bools casted from ints" or "| beetween ints"?
#
# BEGIN CORRECTING PROPOSAL (it will reduce the confusion)
#
To define the predicates
IS_NOT_INVARIANT_OF_LOOP_P (...)
IS_INVARIANT_INCONDITIONAL_OF_LOOP_P (...)
IS_INVARIANT_CONDITIONAL_OF_LOOP_P (...)
IS_NOT_INVARIANT__OR_INVARIANT_INCONDITIONAL_OF_LOOP_P (...)
IS_NOT_INVARIANT__OR_INVARIANT_CONDITIONAL_OF_LOOP_P (...)
IS_INVARIANT_INCONDITIONAL_OR_CONDITIONAL_OF_LOOP_P (...)
note: i don't recommend to use ! with them (except some very rare situations).
(it's complete, good completeness, understandable like natural language)
#
# END CORRECTING PROPOSAL
#
/* Like rtx_equal_p, but attempts to swap commutative operands. This is
important to get some addresses combined. Later more sophisticated
transformations can be added when necessary.
??? Same trick with swapping operand is done at several other places.
It can be nice to develop some common way to handle this. */
static int
rtx_equal_for_prefetch_p (rtx x, rtx y)
{
...
if (COMMUTATIVE_ARITH_P (x))
{
return ((rtx_equal_for_prefetch_p (XEXP (x, 0), XEXP (y, 0))
&& rtx_equal_for_prefetch_p (XEXP (x, 1), XEXP (y, 1)))
|| (rtx_equal_for_prefetch_p (XEXP (x, 0), XEXP (y, 1))
&& rtx_equal_for_prefetch_p (XEXP (x, 1), XEXP (y, 0))));
}
...
}
Why not i can add
if (COMMUTATIVE_ARITH_P (x) || COMMUTATIVE_COMPARE_P (x) || ...) ?
Or will it be a problem in the order of the execution like
the aliasing can affect them,..?
Remember, the binary operators
'+', '*', '==', '!=', '&', '|', '^', ('&&' and '||' are exception) ...
are mathematically commutative. ('-', '/', '%' are not)
a + b <=> b + a a & b <=> b & a
a * b <=> b * a a | b <=> b | a
a == b <=> b == a a ^ b <=> b ^ a
a != b <=> b != a
a && b <=> b && a (with an exception)
a || b <=> b || a (with an exception)
There is an exception because of the short-circuit of && or of || in the
condition of the IF instruction.
It will be difficult or of complex researching if we want or not a
short-circuit of && or of || in the assignment to an condition's variable
instead of in the condition directly.
What is there about the uses of SWAPPABLE_OPERANDS_P?
Only one use in gcc/recog.c and not more places like gcc/loop.c e.g.?
It's nothing!!!
I don't understand the define of SWAPPABLE_OPERANDS_P :
/* 1 if X is a commutative arithmetic operator or a comparison operator.
These two are sometimes selected together because it is possible to
swap the two operands. */
#define SWAPPABLE_OPERANDS_P(X) \
((1 << GET_RTX_CLASS (GET_CODE (X))) \
& ((1 << RTX_COMM_ARITH) | (1 << RTX_COMM_COMPARE) \
| (1 << RTX_COMPARE)))
It's
#define SWAPPABLE_OPERANDS_P(X) \
((1 << GET_RTX_CLASS (GET_CODE (X))) \
& ((1 << 3) | (1 << 1) | (1 << 0)))
It's
#define SWAPPABLE_OPERANDS_P(X) \
((1 << GET_RTX_CLASS (GET_CODE (X))) \
& (8 | 2 | 1))
Yaahhh, i understand it!!!
But it could be a problem of design flaw when extending in the future! :
It could be an easy overflow if is exceeded the limit of 32 values
of an enum!!! (fails if >=33 values in a 32 bit platform)
The trick is only valid if it's for 5-bit enum!!!
Currently, enum rtx_class has 13 values, so, no problem.
I've watched "#if (GCC_VERSION < 2007) ..."
Is it in the past before of the year 2007 ... ? This is a joke!!! ;)
