what determines the time it takes a c function to return?

You haven't provided much to go on, but 3ms (3000 clocks at 1MHz) for a function exit does sound borderline pathological. It is certainly possible to write code which can't be optimized, but this is rather extreme.

The answer to your general question would fill books -- in fact it does. I did my MS in Compiler Design, and I have a great reading list; my guess is that's not what you're looking for.

One way to start would be to generate the assembly code (Properties->Compiler->Advanced->Assembler->Generate Listing File) and look over what was generated for the function exit. Since you're looking for something large, just estimate each instruction as 4 clocks. By the time you count to 100 or so, you'll probably notice the code doing something outlandish. Or, if you're more patient, just step through the individual instructions in the debugger.

Since you're already instrumenting your code, try disabling interrupts before you set the pin high and re-enabling them after setting the pin low. This will prevent unexpected "side-trips". In a highly deterministic system, it is possible (I've seen it many times) for an interrupt to routinely trigger at the same (unrelated) point in the code.

A C function is normally implemented as a block of code that exists once in memory, no matter how often it is used.  When the C function is called, instructions are fetched and executed from memory where the function code is located and afterwards, instructions are fetched from wherever it was before the function was called (just after this place, i.e. the next instructions).  In assembler language, this is like a sub-routine.  What can make a big difference is whether data is passed to the C function, and whether it returns any data on completion.  In C, parameters passed to/from functions are passed via the stack - an area of memory set aside for this purpose (all done automatically behind the scenes so you don't have to worry about it).  For example, a function to add two numbers and return the sum can be implemented as:

int AddTwoNumbers(int a,b)

{return (a+b);}

Then if you call this function, e.g.

Result = AddTwoNumbers(100, 200);

Then the number 100 is placed on the stack, and the number 200 is placed on the stack.  Then the function code is called.  The function code pulls the numbers 100 and 200 off the stack and does the addition, then puts the result back on the stack before returning to the calling code, which then pulls the result off the stack for subsequent use.

Depending on what has to be taken off the stack on completion of the function, it may take some instructions to get everything off the stack, which is what C functions should do to stop the stack growing unnecessarily large.  Might this explain some of the time taken?

As far as I understand it, if a function is declared as inline, then the code of the function is inserted at the point where it is called.  This means that the overhead of switching to a different section of memory for the functions instructions is avoided, so is faster.  I think the complier can also be a bit cleverer about how parameters are passed to and from the inline function, also helping to speed things up.  On the other hand, every time the function is used, the code for the function is present, using more memory.

Tony Payn said:

In C, parameters passed to/from functions are passed via the stack

No. It depends on the compiler and situation how parameters are passed.
The only situation where it is defined how parameters are passed is on a variable parameter list ("...") like in printf.

On MSP, all compilers I know reserve four registers (R12 to R15) for passing up to 4 bytes, two words or one long word to the function and also take the return value. If more parameters are passed, they are passed on stack.
Those 4 registers are considered clobbered after a funciton call (even if a void(void) function is called)
That's why calling a function from within an ISR is counter-productive, because the ISR then has to save and restore them)

If the function returns a float value but the return statement contains an int, then the conversion may take some time. But not 3000 cycles.

Also, upon return, the stack frame (for holding local variables) needs to be removed from the stack, but this too is just a matter of few CPU cycles.

The only reason I can think of for a delay between a return and the instruction after the function call is an interrupt that happens between the two.
Or a recursion in the called function, so the output pin is set on first function entry, but reset on exit of the innermost recursion (and then the outer recursions are completed before actually returning)