similar to: [LLVMdev] Adding CFI checks to clang vs llvm

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

On Tue, Feb 17, 2015 at 07:00:14PM -0800, Chandler Carruth wrote: > On Tue, Feb 17, 2015 at 12:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > Hi, > > > > In http://reviews.llvm.org/D7424 we've been discussing whether to insert > > control flow integrity checks in Clang or LLVM. The main challenge is that > > the checks need

Hi all, I would like to propose a mechanism that would allow LLVM to fold null pointer checks into "nearby" memory operations, subject to runtime support. This is related to but not exactly the same as a proposal floated by Peter Collingbourne earlier [1]. The obvious use cases are managed languages like Java, C# and Go that require a null check on pointers before they're used in

Hi all, I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example,

Hi folks, I've been measuring some devirtualization statistics and I found that when barriers are introduced, the number of functions marked as norecurse is lower. The llvm.group.barrier is obviously norecursive and I've been thinking: is every intrinsic norecurse? I think it make sense to mark all of the intrinsics that can be considered as norecursive this way, so it won't gonna

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using

On Tue, Feb 03, 2015 at 04:03:45PM -0800, Sean Silva wrote: > One other thing: if this can be used for control-flow integrity, I assume > it has to have good knowledge of the available indirect call targets. Could > we also use this information for devirtualization? I would expect so. If a bitset contains only one element, we should be able to teach the lowering pass to simply test that

Andy - If you're not already following this closely, please start. We've gotten into fairly fundamental questions of what a patchpoint does. Filip, I think you've hit the nail on the head. What I'm thinking of as being patchpoints are not what you think they are. Part of that is that I've got a local change which adds a very similar construction (called

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com) wrote: On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames  <listmail at philipreames.com> wrote:  > Andy - If you're not already following this closely, please start. We've  > gotten into fairly fundamental questions of what a patchpoint does.  >  > Filip,  >  > I think you've hit the nail on

> On Oct 31, 2014, at 5:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Kevin, > > Thank you for starting this discussion! Yes, sorry for being unresponsive for a few days. Sanjoy summarized the issues perfectly. > I think the distinction is really between whether the live values are > "live on call" or "live on return".

Hi All, TLDR: Allow calling conventions to be defined on-the-fly for functions in LLVM-IR, comments are requested on the mechanism and syntax. Summary ======= This is a proposal for adding a mechanism by which LLVM can be used to generate code fragments adhering to an arbitrary calling convention. Intended use cases are: generating code intended to be called from the shadow of a stackmap or

On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames <listmail at philipreames.com> wrote: > Andy - If you're not already following this closely, please start. We've > gotten into fairly fundamental questions of what a patchpoint does. > > Filip, > > I think you've hit the nail on the head. What I'm thinking of as being > patchpoints are not what you think

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits

On 04/29/2014 12:39 PM, Filip Pizlo wrote: > On April 29, 2014 at 11:27:06 AM, Philip Reames > (listmail at philipreames.com <mailto:listmail at philipreames.com>) wrote: >> On 04/29/2014 10:44 AM, Filip Pizlo wrote: >>> LD;DR: Your desire to use trapping on x86 only further convinces me >>> that Michael's proposed intrinsics are the best way to go.

Hi all, The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than

Hi all, I'd like to make the following proposal to implement an optimization called virtual constant propagation. ==Introduction== After enabling control flow integrity protection in Chromium, we have observed an unacceptable performance regression in certain critical layout microbenchmarks. Profiling [0] revealed that the cause of the regression was a large number of virtual calls, each

Ask a simple question : I svn checkout compiler-rt in llvm/project. And I compile llvm through cmake. How can I make for all those testing files? make test? - mudongliang 2015-09-02 0:58 GMT+08:00 Kostya Serebryany <kcc at google.com>: > Take a look at > > clang.llvm.org/docs/ControlFlowIntegrityDesign.html > clang.llvm.org/docs/ControlFlowIntegrity.html > > And the