in machine description expanders the functions copy_to_mode_reg
and and force_reg from explow.c can be used to ensure that an operand
lives in a register.
But what function should be used?
What are the differences? The only difference I can depict from the comment
is that an operand returned by force_reg must not be altered, i.e.
overwritten afterwards.
If you just want an operand in a register and want to avoid unnecessary
register-register copies, use force_reg. Note that if the operand was already
in a regsiter, you will retain that register, which may not only be live
after the expanded code, it could also (alterantively or additionally)
be in a hard register or a virtual register, which, depending on the
exact requirements of your instruction pattern. can cause issues
when virtual registers are instantiated or when it comes to register
allocation.
If you want to make sure that you get a pseudo register that you are free to
modify as you whish, use copy_to_mode_reg.
If you want to make your own decision if the value / register should
be copied,
guard a copy_to_mode_reg call with your own condition.
Are there any pitfalls using these functions with respect to
reload_completed, reload_in_progress or no_new_pseudos?
Yes and no. You should never, ever do that during / after reload. But that
is not considered a pitfall, but obvious.
By the way: Are there better places to ask such questions like in gcc-help?
If you actually need a new gcc backend and want it to be done well. you
should instruct an experienced contractor to do it for you, or hire an
in-house expert.
Your question reveals that you are not familiar with gcc, and further
suggests that you are trying to implement a new backend alone or in a team
lacking a gcc expert. This is likely to either fail or result in a
backend of substandard quality which will never make it into the FSF
repository.
You might eventually (after several years) improve and come up with a
proper backend, but you will likely pick up the necessary skills more
quickly if you start out with something less ambitious, like improving
an existing backend, and have your patches peer-reviewed on the gcc
mailing list.
Or if you directly cooperate in implementing your new backend with someone
who already has the necessary experience.
Thus, although your orginal question is valid in principle on this list,
answering is not likely to really help you, nor are you likely to help
the GCC community in the forseeable future if you are working on an
over-ambitious project project.
Thus, there is little incentive for anybody knowledgable reading this
list to answer this question.
If the same question had been asked in a different context, e.g. a small
patch to the x86 backend in order to support some new and exciting linux
application, the odds of getting a timely response would have been higher.
It's hard to believe that all the existing gcc backends are written by
copy & past and trial & error, rather than by understand & implement.
If you know what you are doing - i.e. you already understand the subject
matter - copy & past & adjust can be a useful tool:
If you know that the backend you are implmeneting shares certain aspects with
an existing target, you can copy & paste the code that deals with these
aspects and adjust to fit.
And of course a lot of code is written from scratch according to spec. Its
just that documentation and comments tend to focus on things that people
think merit documenting. force_reg and copy_to_mode_reg are rather simple
functions, so just glancing at the source tells you what they do.
Of course, if you have a copyright assignment on file, you can submit a patch
to improve the documentation in places where you think it is lacking.
Concerning the GCC internals: What place is the best to get the most
up to date version of it? The online version has several
inconsistencies, so it is very hard to understand and remove
sophisticated backend problems and defiecencies.
You can also read the doc/*.texi files from the subversion repository.
If you find an inconsistency in the documentation, please post the issue
to the list.
