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

[Robinson, Paul via llvm-dev]

Sounds like such a security-sensitive value would need to treat calls as barriers for any kind of reordering.
Also, at the end of the value's live range, it would not have to be merely dead, but dead-and-buried (i.e. overwritten) to avoid scavenging by subsequent callees. Same goes for merely copying the value from one register to another, the source would have to be erased.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Stephen Crane via llvm-dev
Sent: Monday, November 02, 2015 4:08 PM
To: Smith, Kevin B
Cc: llvm-dev at lists.llvm.org; Per Larsen; Andrei Homescu
Subject: Re: [llvm-dev] How to prevent registers from spilling?

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<mailto: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/20151103/882039cc/attachment-0001.html>