<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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?</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Nov 2, 2015 at 3:47 PM, Smith, Kevin B <span dir="ltr"><<a href="mailto:kevin.b.smith@intel.com" target="_blank">kevin.b.smith@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those<br>
into SSA values when optimization proves that is OK.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
You cannot put an unspillable value in a callee preserved register, because you cannot know whether the callee may save that or not.<br>
And if it is in a caller-save register, then the caller has to spill it if it is live across a call.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>- stephen</div></div></div></div>