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: question about registers that are set on entry to a function.


Ian Lance Taylor wrote:
Kenneth Zadeck <zadeck@naturalbridge.com> writes:

1) Do you believe that this code could be correct?

Well, no.


You do not have to sugar coat it, I can handle the truth.
2) Most of the paragraphs are protected by either reload_completed or
epilogue_completed (which has a comment at the its point of
declaration that it is true for both the prologue and epilogue). Is
it true that after these epochs, that there will really be code in the
first basic block that will def these registers? I.e. are any of them
implicitly set before the function is called so I will not find a def?

This isn't quite accurate. When the RTL is initially generated, for any values passed in parameters you will see at the start of the function (set (pseudo-reg) (param-reg)) That is, parameter handling is independent of the prologue/epilogue code, and thus independent of epilogue_completed. If you want to declare that all FUNCTION_ARG_REGNO_P registers are live, you should do that regardless of epilogue_completed.

Actually FUNCTION_ARG_REGNO_P is not enough.  It returns true for
outgoing function registers.  On a target with register windows, at
the start of the function you need to apply INCOMING_REGNO to each
register for which FUNCTION_ARG_REGNO_P returns true.

The prologue code which is set up when epilogue_completed is true is
code which sets up the stack frame and saves the callee saved
registers on the stack.  So when epilogue_completed is true, then at
the start of the function you will probably want to treat as live
every callee saved register for which regs_ever_live is true.  For
some targets the frame pointer will be live on function entry, for
others it is initialized by the prologue if necessary.

Assuming that PIC_OFFSET_TABLE_REGNUM is defined isn't always going to
be correct, although it may not matter.  On some targets, e.g., i386,
the register will be defined by the prologue code anyhow.

This all seems doable. I can spin a better version of this.

3) Am I missing any classes of registers?

For complete accuracy, there are probably going to be some target specific registers which need to be handled, unfortunately. For example, on MIPS, with -mabicalls (which is the default on GNU/Linux), $25 is live on function entry. It holds the address of the function, and is used to initialize $28, which is PIC_OFFSET_TABLE_REGNUM. I don't think there is any target independent way of getting at that fact.

Is the right thing to do to define a target hook for this that defaults to doing nothing and we only define it in those places where necessary or should I add a few other macros to the ports as necessary and just check to see if they are defined? I have noticed that there are several macros that are only used on a single port.

It is also worth noting that rather than assuming that all
FUNCTION_ARG_REGNO_P registers are live, you could use
FUNCTION_ARG/FUNCTION_ARG_ADVANCE to walk through the parameters and
determine precisely which ones are live.  I don't know whether that
will make a significant difference for the rest of the code, though.

I will look into this also.

Ian



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