Kaz Kojima wrote:
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
Sorry, I forgot that this is specified to depend on fpscr, and that we
are running
optimize_mode_switching before reload now. This makes this solution
unusable
for TARGET_FMOVD. This means we need to go the secondary / tertiary reload
route. (At least for TARGET_FMOVD - we can use a special constraint to mean
FP_REGS if !TARGET_FMOVD and NO_REGS if TARGET_FMOVD.)
I'll try it, though the secondary/tertiary reload stuff may be beyond
me.
Hmm, I see we have a conflict on reload_insi. There can only be one
reload pattern
per direction and mode. And push_secondary_reload only generates
tertiary reloads
on behalf of reload patterns.
I suppose we could have push_secondary_reload set t_class in the
(icode == CODE_FOR_nothing) case. That would make it simple to write
ports where multiple temporary registers are needed.
On the other hand, we'd have to make sure that we get the actual reload
emitting right,
since we now created a new case - and there'd still be the problem of
possible
clashes where you genuinely need two conflicting reload patterns .
An approach that soves these issues would be to change push_secondary_reload
to parse multi-alternative reload patterns. Now that we have
multi-character constraints,
we can use a special constraint in the place of a predicate. So
push_secondary_reload
could first try to find a match that satisfies not only the
operand[in_p] constraint for
the to-be-reloaded operand, but also has an operand[!in_p] constraint
(insn_class)
matching the reload_class, and an operand[2] constraint matching the
secondary
reload class. If that fails, it can choose the first match where the
operand[in_p] constraint
matches the operand and the operand[!in_p] constraint matches reload_class.
For backward compatibility, we can treat a single-alternative reload pattern
like we do now, i.e. consider it matching if the operand predicate
matches, no
matter what the constraints say.
