llvm dev - Nov 2011 - [LLVMdev] Inserting stack spilling code that modifies globally visible state

Hello,
I am developing compiler for the 8-bit PicoBlaze processor in LLVM 2.9.
The problem at hand is that the stack spilling code in this
architecture modifies the machine FLAGS register (i.e. globally
visible state). The LLVM core code does not know about this 'feature'
and happily inserts spilling code anywhere it wants, thus
(potentially) corrupting live FLAGS.

Practically, the FLAGS register is used only for multi-byte arithmetic
(ADD+ADDCY pair), and conditional jumps (COMPARE+JUMP pair). Thus the
FLAGS register live-range, which is correctly (I hope) expressed in
the IR and it is visible to the reg. allocator and to all the existing
machinery, is usually very short. All I need is that the spilling code
would be never inserted into a live range of the FLAGS register. Is
this possible?

(As a side note: I tried to work-around the problem by moving the
spilling code around "by hand" in
TargetInstrInfoImpl::loadRegFromStackSlot / storeRegToStackSlot, but
that is too late because physical registers are already allocated by
then and thus it is not always possible to move the spilling code
around without disturbing other register data dependencies.)

Thanks,
  Jara

-- 
Space--the final frontier!

On Nov 9, 2011, at 4:20 AM, Jaroslav Sýkora wrote:
> Hello,
> I am developing compiler for the 8-bit PicoBlaze processor in LLVM 2.9.
> The problem at hand is that the stack spilling code in this
> architecture modifies the machine FLAGS register (i.e. globally
> visible state). The LLVM core code does not know about this
'feature'
> and happily inserts spilling code anywhere it wants, thus
> (potentially) corrupting live FLAGS.
Right, the register allocators expect to be able to insert spill/fill/copy
instructions almost everywhere. (The only exception is after a terminator).

This will happen much more aggressively one you upgrade to 3.0.
> Practically, the FLAGS register is used only for multi-byte arithmetic
> (ADD+ADDCY pair), and conditional jumps (COMPARE+JUMP pair). Thus the
> FLAGS register live-range, which is correctly (I hope) expressed in
> the IR and it is visible to the reg. allocator and to all the existing
> machinery, is usually very short. All I need is that the spilling code
> would be never inserted into a live range of the FLAGS register. Is
> this possible?
Your best bet is to model these instruction sequences as VLIW bundles.

Currently, the best way of doing that is to create pseudo-instructions
representing cmp+jmp etc.
> (As a side note: I tried to work-around the problem by moving the
> spilling code around "by hand" in
> TargetInstrInfoImpl::loadRegFromStackSlot / storeRegToStackSlot, but
> that is too late because physical registers are already allocated by
> then and thus it is not always possible to move the spilling code
> around without disturbing other register data dependencies.)
Exactly. That won't work.

/jakob