similar to: [LLVMdev] Enhancing BasicAliasAnalysis for Rust

Hi, I want to add a stack probe function attribute which would insert stack probes on all platforms, not just Windows. This will be useful for Rust since it must guarantee that the stack can't overflow, which it currently abuses the segmented stack support for. I'm not sure which kind of attribute is appropriate here. It must be added to the caller when inlined and clients of LLVM should

On Fri, Aug 1, 2014 at 11:12 PM, Philip Reames <listmail at philipreames.com> wrote: > Thanks for the explanation. I'm used to hearing the term "stack banging" > used for this mechanism, but I understand your objective. > > I believe having a general mechanism here would be valuable, but only if > the implementation doesn't make assumptions about runtime

The point of this is to cheaply detect all stack overflows using a guard page. For a guard page to actually detect all stack overflows, we need to ensure that the code touches each page of the stack in the right order, otherwise it could skip the guard page and write outside the stack. That is very bad for languages such as Rust which provides memory safety, so it currently does an explicit

Yeah, the function attributes section of LangRef is a reasonable place to put stuff like this: http://llvm.org/docs/LangRef.html#function-attributes I think we should add this. I also know that LLILAC needs something like this as well. I propose the following: - Add a string attribute called "stack-probe-symbol"="foo". - The presence of this attribute indicates that stack

Would the __probestack functions be a suitable addition to compiler-rt? Does it already have __chkstk or is that provided by something else on Windows? I noticed that libgcc implemented them in cygwin.S. On Mon, Aug 4, 2014 at 9:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/01/2014 05:38 PM, John Kåre Alsaker wrote: > > On Fri, Aug 1, 2014 at 11:12 PM,

Since David Majnemer doesn't seem overly eager to merge my patches, let's see if we can't figure things out here. I noticed a string function attribute appeared in LangRef.rst, would that be the correct place to document this? For reference: http://reviews.llvm.org/D9653 http://reviews.llvm.org/D9654 http://reviews.llvm.org/D9858 On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker

This used to be a single patch, but I split it into two with the addition of struct Scatterlist. Again a bit new with Rust submissions. I was told by Gary Guo to rebase on top of rust-next, but it seems *very* behind? The first patch does not build on its own due to a dead_code warning. It is hard to not have dead code when one is adding infrastructure to be used by others at a later

On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker < john.mailinglists at gmail.com> wrote: > On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: > > Yeah, the function attributes section of LangRef is a reasonable place to > > put stuff like this: > > http://llvm.org/docs/LangRef.html#function-attributes > I'll see if I can't

I updated http://reviews.llvm.org/D4717 and also wrote an __probestack implementation: https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe Which instruction would be the preferable one to probe with? I used OR since that's what GCC/libgcc does, but I don't see why that would be better than a write. On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at

Phabricator seems to like to send emails with zero content to the list with relatively high frequency, like this: > From: Ikhlas Ajbar <iajbar at codeaurora.org> > Subject: Re: [PATCH] Remove unused function HasPICArg(). > To: iajbar at codeaurora.org, bcahoon at codeaurora.org > Cc: llvm-commits at cs.uiuc.edu > Date: Tue, 19 May 2015 18:29:30 +0000 (6 hours, 21 minutes, 32

On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: > Yeah, the function attributes section of LangRef is a reasonable place to > put stuff like this: > http://llvm.org/docs/LangRef.html#function-attributes I'll see if I can't sneak something in there. > > I think we should add this. I also know that LLILAC needs something like > this as

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >

I fixed based on comments. I'll send these two patches to this mailing list. - Fix Handle -> Handle<'a> - Add events Regards, Hiroyuki 2019年8月1日(木) 0:01 Pino Toscano <ptoscano@redhat.com>: > Hi Hiroyuki, > > On Tuesday, 30 July 2019 07:51:37 CEST Hiroyuki Katsura wrote: > > This patch includes: > > > > - Event callback handlers > > -

This is the first patch I've sent to this project. Please be gentle :) LLVM fails to remove the dead load in the following code when running $./llvm-as -o - test.ll | ./opt -O3 -o - | ./llvm-dis -o - %t = type { i32 } declare void @foo(i8*) define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 %before = load i32* %p call void

Here is another change I'd like to suggest to the BasicAliasAnalysis. LLVM fails to remove the dead store in the following code: %t = type { i32 } define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 store i32 1, i32* %p; <-- This store is dead %x = load i32* inttoptr (i32 12345 to i32*) store i32 %x, i32* %p ret

Hi! I think there is a break missing in switch statement of AddressMightEscape function. It causes redundant recurrent call. Wojtek -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BasicAliasAnalysis.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070903/481046a5/attachment.ksh>

On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > Here is another change I'd like to suggest to the BasicAliasAnalysis. > > LLVM fails to remove the dead store in the following code: > > %t = type { i32 } > > define void @f(%t* noalias nocapture %stuff ) { > %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 > > store i32 1, i32* %p; <-- This

Hello @R-devel I needed some statistical functions for a project I was working on in Rust, and I've used the R math library as a standalone solution. I thought the R developers would be interested in the fact that their work is being used elsewhere, and I also wanted to say thanks for some code I do NOT want to have to write myself! The "crate" (Rust's name for a package) is at

From: Asahi Lina <lina at asahilina.net> DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,