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]

Re: The secondary reload


Paul Koning <paul_koning@dell.com> writes:

>
> I don't know enough to answer that.  But I do know that the secondary
> reload stuff works great, and is reasonably well documented, and it
> takes only a few lines to put into effect.  Why not give it a try?

Thanks for your input Paul.
Actually the problem is exactly that. I have inherited code with a
secondary reload which 'forwards' the code to a insn that requires split
and I have a gut feeling that something here is not quite right and
could be simplified. My initial thought was... I will remove the
secondary reload and try to go without it cause I haven't understood why
we need it. There's always one register class that is able to load/store
from memory and even though not all register classes can have move
between themselves I think the solution I showed using a scratch
register would make sense for those cases.

In the meantime, you might be know the following. Sometimes, the
secondary reload brings something already in sri->icode, meaning it is
not always CODE_FOR_nothing. Which value is this? The manual doesn't
mention any default for sri->icode.

-- 
PMatos


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