On 11/02/2009 09:37 AM, Richard Henderson wrote:
Note that with char values, we do
eliminate the AND operation, so this is not (any longer) about some pass
not understanding STORE_FLAG_VALUE.
... or maybe it is. We probably should have eliminated the AND at the
gimple level.
r~
On 11/01/2009 04:03 PM, Paolo Bonzini wrote:
An andl
#1 after a seq is 1 to 1, but how should compiler know that?
I don't understand the last sentence.
I think it's talking about something like
int f(int x, int y)
{
int r;
r = x == y;
r &= 1;
return r;
}
cmpl%esi, %edi
On 11/02/2009 08:49 AM, Joern Rennecke wrote:
This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or you'
Quoting Joern Rennecke :
Quoting Paolo Bonzini :
...
That would be:
clr r7
clr r8
...
move strict-low-part(r7), r0
...
move strict-low-part(r8), r1 --> could reuse r7
This is not implemented but IMHO obsolete, most of the targets will
just use an AND to implement zero extension.
If the tar
Quoting Paolo Bonzini :
Possible special combination pattern: If the two
operands to a comparison die there and both come from insns that are
identical except for replacing one operand with the other, throw away
those insns. Ok if insns being discarded are known 1 to 1. An andl
#1
Possible special combination pattern: If the two
operands to a comparison die there and both come from insns that are
identical except for replacing one operand with the other, throw away
those insns. Ok if insns being discarded are known 1 to 1. An andl
#1 after a seq is 1 to 1
At http://gcc.gnu.org/projects/#the_old_problems_file we have a short
list coming from the GCC 2 PROBLEMS file. Instead of carrying this
around forever, I am wondering whether we could quickly review these
and either remove (as not applicable any longer) or move to Bugzilla?
Possible special co
