[llvm-dev] How to prevent registers from spilling?

[Stephen Crane via llvm-dev]

Thanks, I hadn't thought about the HPC applications. I'm not sure that the
requirements for the HPC and security use-cases are compatible. Pinning for
performance can tolerate spills if it is still fast, while security uses
can tolerate slow rematerialization but not spills. Maybe a shared
infrastructure is possible but with variable constraints?

On Mon, Nov 2, 2015 at 3:47 PM, Smith, Kevin B <kevin.b.smith at intel.com>
wrote:

> That breaks the whole IR idea of using alloca to allocate/denote space for
> local variables, and then optimize those
> into SSA values when optimization proves that is OK.
>

Agreed, but the values I care about (which is not really the HPC use-case)
would actually be values internal to the compiler, such as the location of
CFI metadata, which are never exposed to the front end. Thus I would be
happy with something at the machine IR level, after that abstraction has
been lost.


> Also, for a lot of things, that attribute is simply impossible to
> implement.  Any value that is live across a call needs to be spilled to
> memory.
> You cannot put an unspillable value in a callee preserved register,
> because you cannot know whether the callee may save that or not.
> And if it is in a caller-save register, then the caller has to spill it if
> it is live across a call.
>

Yes, but what about values that can be rematerialized? Of course values
that _need_ to be live across calls are out, but I'm more concerned about
values that were coalesced, hoisted, and which then get spilled. Maybe
prevention of coalescing for sensitive values and explicitly inserting
materialization at each use is an option here, although that sounds like
teaching a lot of passes about sensitive values, with no guarantee of
finding all of them. Wouldn't the register allocator still need to make
sure that sensitive values are not present in dead callee-saved registers,
so they don't get accidentally spilled by a callee?

- stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/9c9ef11f/attachment.html>