This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

reload_in<mode> conflicts (Was: Re: [patch RFC] SH: PR target/21623)


Kaz Kojima wrote:

Joern RENNECKE <joern.rennecke@st.com> 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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]