Question: You've just written a pile of code to deliver some important feature under pressure. You've cut a few corners, you've mashed some code into some over-bloated classes with names like SerialIndirectionShutoffManager..

You tell your boss you're going to need a week to clean this stuff up.

"Clean what up?"

"My code - its a pigsty!"

"You mean there's some more bug fixing?"

"Not really, its more like.."

"You're gonna make it run faster?"

"Perhaps, buts thats not.."

"Then you should have written it properly when you had the chance. Now I'm glad you're here, yeah, I'm gonna have to go ahead and ask you to come in this weekend.. "

I've read Matin Fowler's book, but I'm not sure I agree with his advice on this matter:

* Encourage regular code reviews, so refactoring work is encouraged as a natural part of the development process.
* Just don't tell, you're the developer and its part of your duty.

Both these methods squirm out of the need to communicate with your manager.

What do you tell your boss?

Answer: 
Just do it and schedule it into your normal process. Estimate refactoring time into starting a new change or into finishing a change (ideal).
I always refactor while I'm initially exploring new code (extracting methods, etc).
In one of Robert Glass's recent books (I'll have to look up the reference) he mentioned a study on the cost of well maintained code. What they found is that well maintained code was edited more often than poorly maintained code. That sounds counter intuitive but when they dug deeper the discovered the reason:

Well maintained code has more features added to it in the same time frame than poorly maintained code.

Does your Boss like features? Sure, they all do. If more you improve the maintainability of the code, the more features you will be able to deliver with that limited budget.