RE: RFC cse weirdness

2006-05-17 Thread Dave Korn
On 15 May 2006 15:47, Andreas Krebbel wrote: > [rA + rB] = [rA + rB] & 3; > 1. SRC rB -> rD > 2. SRC rA -> RC > 3. DEST rB -> rD > 4. DEST rA -> RC > last 3 changes. If the subsequent call to apply_change_group fails we > end up with: > > [rA + rB] = [rA + rD] & 3; > Which now could still be i

Re: RFC cse weirdness

2006-05-17 Thread Andreas Krebbel
Hi Dave, thanks for your comments. > Doesn't this mean that your insn patterns should be using numerical (aka > "matching") constraints? Oh we are using matching constraints. But of course nobody except reload does care about them. If the only constraints for an operand are matching constrain

RE: RFC cse weirdness

2006-05-23 Thread Dave Korn
On 17 May 2006 19:48, Andreas Krebbel wrote: >> Doesn't this mean that your insn patterns should be using numerical (aka >> "matching") constraints? > > Oh we are using matching constraints. But of course nobody except reload > does care about them. If the only constraints for an operand are mat

Re: RFC cse weirdness

2006-05-23 Thread Andreas Krebbel
Hi, > Hmm. I note that if you /were/ using match_dups, the problem would be > solved because all four changes would go through the 'then' clause of the > if...else construct. Maybe it would be more worthwhile for you to have > separate patterns after all and find some other way of making reloa

RE: RFC cse weirdness

2006-05-23 Thread Dave Korn
On 23 May 2006 15:42, Andreas Krebbel wrote: > Hi, > >> Hmm. I note that if you /were/ using match_dups, the problem would be >> solved because all four changes would go through the 'then' clause of the >> if...else construct. Maybe it would be more worthwhile for you to have >> separate patt

Re: RFC cse weirdness

2006-05-23 Thread Andreas Krebbel
Hi, > The x86 pattern is called "anddi_1_rex64", which is not one of the standard > names: that means the compiler will never emit it directly. Not necessarily. Someone simply could call gen_andidi_1_rex64 (e.g. from i386.c) to emit this pattern. That the insn doesn't use a standard name only

Re: RFC cse weirdness

2006-05-23 Thread Andreas Krebbel
> An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" > expander. "must not" should be replaced here by "does not need to" a common error for Germans ... or well at least for me ;-)

Re: RFC cse weirdness

2006-05-23 Thread Joe Buck
On Tue, May 23, 2006 at 07:29:59PM +0200, Andreas Krebbel wrote: > > An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" > > expander. > "must not" should be replaced here by "does not need to" > a common error for Germans ... or well at least for me ;-) A German colleague of mi

Re: RFC cse weirdness

2006-05-24 Thread Bernd Schmidt
Andreas Krebbel wrote: when cse replaces registers in an insn it tries to avoid calls to validate_change, what causes trouble in some situations. From validate_canon_reg: /* If replacing pseudo with hard reg or vice versa, ensure the insn remains valid. Likewise if the insn has MATCH_

Re: RFC cse weirdness

2006-05-24 Thread Andreas Krebbel
Hi, > On those grounds, please submit a change to fix both places in > cse.c. If we run into further problems of this kind, we'll have to > rethink whether such patterns are valid. Ok. I'll do so as soon as possible. Unfortunately the trivial fix of just removing the else branch doesn't work.