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.
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_
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
> 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 ;-)
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
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
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
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
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
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
10 matches
Mail list logo
