search for: seaborn

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead...

...d? - Can frame pointers be disabled on all architectures? If not, is the frame pointer chain always walkable? - Can frame pointers be disabled on a per-function basis? (this is in case not the whole program's stacks need to be made relocatable). Vadim On Thu, Jan 23, 2014 at 8:22 AM, Mark Seaborn <mseaborn at chromium.org> wrote: > On 22 January 2014 22:10, Vadim <vadimcn at gmail.com> wrote: > >> Hi, >> I am toying with an idea of having LLVM generate code that has >> position-independent stacks. This would be a very useful property for >> imple...

The PNaCl project has implemented various IR simplification passes that simplify LLVM IR by lowering complex features to simpler features. We'd like to upstream some of these IR passes to LLVM. We'd like to explore if this acceptable, and if so, how we should go about doing this. The immediate reason is that Emscripten is reusing PNaCl's IR passes for its new "fastcomp"

On Tue, Mar 4, 2014 at 3:11 PM, Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Mar 4, 2014 at 4:04 PM, Mark Seaborn <mseaborn at chromium.org>wrote: > >> The PNaCl project has implemented various IR simplification passes that >> simplify LLVM IR by lowering complex features to simpler features. We'd >> like to upstream some of these IR passes to LLVM. We'd like to explore if...

...s any data structures of the host program directly. The only communication way is by using syscalls, but the document does not specify syscalls in detail. How the syscalls are represented in LLVM IR ? What kind of data structures can be passed ? Best, Dmitri Am 19.06.2013 01:36, schrieb Mark Seaborn: > On 18 June 2013 15:27, Dmitri Rubinstein > <dmitri.rubinstein at googlemail.com > <mailto:dmitri.rubinstein at googlemail.com>> wrote: > > Is it possible to use PNaCl infrastructure (i.e. translation and > execution in a sandbox) without a Chrome ? > >...

On 18 June 2013 15:08, Sean Silva <silvas at purdue.edu> wrote: > On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > >> On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: >> >>> Instead of a blacklist, why not a whitelist? Given the size of LangRef, >>> you're bound to leave something out

On 18 June 2013 15:27, Dmitri Rubinstein <dmitri.rubinstein at googlemail.com>wrote: > Is it possible to use PNaCl infrastructure (i.e. translation and execution > in a sandbox) without a Chrome ? > > I mean a something like a standalone VM like Java or Mono/C#. > Yes. The NaCl tool 'sel_ldr' will run a program inside a sandbox outside of the web browser. We do a

Hi, I am toying with an idea of having LLVM generate code that has position-independent stacks. This would be a very useful property for implementing all sorts of micro-thread libraries (I am thinking something similar to Python greenlets <http://stackoverflow.com/a/17447308>), because you'd be able to easily save threadlet state from one OS thread and later restore it into another.

Hi Mark, On 2013-08-02 04:11, Mark Seaborn wrote: > That note in the documentation seems to be incorrect, because LLVM > will do tail call optimisations on at least x86 when using the "ccc" > calling convention. For example: > > $ cat tail_call1.c > void foo(int arg); > void bar(int arg) { > foo(arg); &...

...ffering a large performance loss on OS X with clang due to the inability to dedicate a register for fast access to thread-local storage. Renato Golin [followed up](http://article.gmane.org/gmane.comp.compilers.llvm.devel/72378) with how he thinks it is best to move forwards on the issue, while Mark Seaborn [shared a neat trick the NaCl team use](http://article.gmane.org/gmane.comp.compilers.llvm.devel/72375) where they inline `pthread_getspecific` after verifying it contains the code they expect. * Kostya Serebryany [shares his concerns about contention between threads on access to profile counters]...

On 1 August 2013 00:11, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > we've published an initial version of the PNaCl bitcode reference > > manual online - > > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > > bitcode is a restricted subset of LLVM IR. > > > > Any comments would be

On Tue, Mar 4, 2014 at 6:17 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Mar 4, 2014 at 1:04 PM, Mark Seaborn <mseaborn at chromium.org>wrote: > >> The PNaCl project has implemented various IR simplification passes that >> simplify LLVM IR by lowering complex features to simpler features. We'd >> like to upstream some of these IR passes to LLVM. We'd like to explore if...