A blast from the past
law@redhat.com
law@redhat.com
Thu Jan 3 11:29:00 GMT 2002
I was looking deeper into the issues surrounding prs 5169, 5185 and 5264
and it would be useful if you could recall details surrounding a very old
patch.
Thu Apr 4 07:34:17 1991 Richard Kenner (kenner at vlsi1.ultra.nyu.edu)
[ ... ]
* combine.c (try_combine): If we have a PARALLEL of a SIGN_EXTEND
and a load of memory, split it into a load and SUBREG assignment.
(find_split_point): If we have LO_SUM for this machine,
split (mem (symbol_ref ..)) using HIGH and LO_SUM.
If we have operation with second operand constant, maybe we couldn't
fit the constant in the insn, so try to split there.
Move NOT to first operand so we'll try to split the other operand
first.
(subst): No reason to avoid making paradoxical SUBREGs and we miss
some optimizations if we don't.
Convert (lo_sum (high FOO) FOO) to FOO.
Convert (C1 + (x + C2) to (C1 - C2) - x.
Use distributive law in more places with logical operations.
(apply_distributive_law): Properly distribute IOR over XOR.
(simplify_shift_const): Simplify (ashift (plus ..) ...).
(simplify_comparison): Add code to remove extraneous AND
operations when comparing result of two comparisons on some machines.
Ignore bits not applicable in our mode.
Treat some SUBREGs as ZERO_EXTENDs.
Convert equality comparison of AND with sign bit into LT or GE
comparison.
The actual code from simplify_comparison:
/* Now make any compound operations involved in this comparison. Then,
check for an outmost SUBREG on OP0 that is not doing anything or is
paradoxical. The latter case can only occur when it is known that the
"extra" bits will be zero. Therefore, it is safe to remove the SUBREG.
We can never remove a SUBREG for a non-equality comparison because the
sign bit is in a different place in the underlying object. */
op0 = make_compound_operation (op0, op1 == const0_rtx ? COMPARE : SET);
op1 = make_compound_operation (op1, SET);
if (GET_CODE (op0) == SUBREG && subreg_lowpart_p (op0)
&& GET_MODE_CLASS (GET_MODE (op0)) == MODE_INT
&& GET_MODE_CLASS (GET_MODE (SUBREG_REG (op0))) == MODE_INT
&& (code == NE || code == EQ)
&& ((GET_MODE_SIZE (GET_MODE (op0))
> GET_MODE_SIZE (GET_MODE (SUBREG_REG (op0))))))
{
op0 = SUBREG_REG (op0);
op1 = gen_lowpart_for_combine (GET_MODE (op0), op1);
}
[ ... further twiddling to attempt to remove SUBREGs for op0 ... ]
What I'm trying to figure out is why you didn't try to remove any SUBREGs
for op1 in a manner similar to how you try to remove them for op0.
Not removing the SUBREG for op1 is hiding a latent bug exposed by the
problem reports mentioned above. But I would like to have a better
understanding of this code before tweaking it to handle op0 and op1 in
a consistent manner. Any insight you could provide would be helpful.
jeff
More information about the Gcc
mailing list