similar to: [LLVMdev] Empty emails from phabricator

On 5/19/15 7:02 PM, Matthias Braun wrote: > They happen for things like closing a revision, adding dependencies or subscribers. But I agree that they are pretty useless because they don't actually mention the action that triggered the mail but just contain the accompanying comment which may be empty. Last time I brought this up, I was pointed at Phabricator's Phabricator as the place

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

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

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

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

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,

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

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

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

Since Rust references usually never aliases it would be nice if we could exploit this for code generation. One idea I had to improve alias analysis is to insert metadata on pointer loads. !inheritalias could be added to load instructions to indicate that if we know all the aliases of the pointer we load from, then we also know all the aliases of the pointer value loaded. Given that pointer loads

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > 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 >>

Alexey, I got mail from one of the tsan buildbots, claiming a breakage in tsan tests. But I cannot see anything on the logs it has for the build. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/run%2064-bit%20tsan%20unit%20tests/logs/stdio Any ideas? Thanks. Diego. ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed,

On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > It's a 20m timeout without output. > > If you back up to the build and look at the 'annotate' step output, > there's this text: > > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/annotate/logs/stdio > > -- Testing: 258 tests, 16 threads -- >

+dvyukov On Wed, May 13, 2015 at 11:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > >> It's a 20m timeout without output. >> >> If you back up to the build and look at the 'annotate' step output, >> there's this text: >> >>

Happened to me again: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/18273/steps/annotate/logs/stdio In fact, this whole bot has a 20% failure rate with the same failure mode, from looking at the history: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/?numbuilds=50 They all end with this: [100%] Running ThreadSanitizer tests -- Testing: 258 tests, 16 threads --

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

Hi James, I also think that refactoring the code generation part is a great idea. That code is very complicated and difficult to maintain. I’ve wanted to rewrite that code for a long time, but just have never got to it. There are quite a few edge cases to handle (at least in the current code). I’ll take a deeper look at your patch. The abstractions that you mention, Stage and Block, are good

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the