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