On 04/28/2016 05:18 AM, Torsten Duwe wrote:
On Thu, Apr 28, 2016 at 11:39:48AM +0300, Maxim Kuvyrkov wrote:
On Apr 27, 2016, at 6:22 PM, Torsten Duwe <d...@suse.de> wrote:
Your current patch is great for experiments for the kernel engineers to check
if suggested approaches to code patching will work. Still, I prefer to
implement LTO-friendly way of handling -fprolog-pad=N via function attributes.
That was exactly my intention. I only wanted *some* working compiler.
I'm sure you compiler people will have a better way to finally implement this.
Conceptually we have the concept of nops insn patterns, so generically
I'd implement this by emitting a suitable set of nops followed by a
scheduling barrier, then thread the mess at the start of the prologue.
This would be 99.9% target independent changes.
We'd just punt targets that don't represent prologues as RTL.
All I can say so far about the ipa-ra issue is that it'd be great if
x9(?) could be left as volatile / scratch; the rest can be preserved.
ipa-ra doesn't really work that way. It just notes what's used in the
callee and the caller is allowed to look at that information and use it
to optimize stuff on the caller side.
For example, call-clobbered registers that are not used in the callee
can be used in the caller to hold values across the call.
This is going to wreck havoc for anything that assumes a call-clobbered
register can always be safely used in the callee, particularly in the
patched codepath. One could argue that the patched codepath is the
uncommon case and should be responsible for saving/restoring any
register it uses to ensure it doesn't mess up any visible state.
Jeff
