llvm dev - Sep 2011 - [LLVMdev] Marking machineinstructions that are spills generated by register allocation

Our TCE backend (which is not in the official llvm repo) benefits 
greatly from information that which memory load/store is a spill 
generated by register allocation.

These spill memory operation can never alias with other memory 
operations, and our own instruction scheduler can optimize much better 
with better alias information.


I have created a code which adds marking these spill instructions to the 
register allocators of llvm.

In my implementation spills are marked into spill Machine instructions 
with MIFlag, adding there a flag bit for spills
(currently there is only one flag bit, "FrameSetup" which is only used
by x86 backend)

My implementation requires just one 9-line function to VirtRegMap class,
and a single call to that function in all register allocators.

Does this sound reasonable/is there hope of getting this patch through 
to llvm 3.0 even though currently it only helps only one "unofficial" 
backend?

This spill marking information might have also some other uses on some 
other backends and might also help debugging.

And if it should be done differently, how? By adding some command 
line/configuration option which controls whether the marking is done or not?

Should I just send my patch to llvm-commtis as it is now?

On Sep 29, 2011, at 2:19 AM, Heikki Kultala wrote:
> Our TCE backend (which is not in the official llvm repo) benefits 
> greatly from information that which memory load/store is a spill 
> generated by register allocation.
> 
> These spill memory operation can never alias with other memory 
> operations, and our own instruction scheduler can optimize much better 
> with better alias information.
This information is available from the instruction's memory operands.

See EmitComments() in lib/CodeGen/AsmPrinter/AsmPrinter.cpp.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110929/f3716ca9/attachment.html>