search for: safeness

...> distinguish it from hand-written assembly code by checking if there's a gap > between symbols, can we just assume a section with no gap is always "safe"? Gaps could just be caused due to alignment, but the code may be safe, which the compiler knows very well. > - "Safeness" is not an attribute of the section but of the symbol, I > think. The symbol is "safe" if there's no direct reference to the symbol > data. All references should go through relocations. A section may contain > both "safe" and "unsafe" symbols. Section...

...t; is the best approach, though. Some comments. - If the compiler generated code is always "safe", and if we can distinguish it from hand-written assembly code by checking if there's a gap between symbols, can we just assume a section with no gap is always "safe"? - "Safeness" is not an attribute of the section but of the symbol, I think. The symbol is "safe" if there's no direct reference to the symbol data. All references should go through relocations. A section may contain both "safe" and "unsafe" symbols. - How about making th...

Hi, Currently lld ties up all atoms in a section for ELF together. This proposal just breaks it by handling it differently. *This requires **NO ELF ABI changes. *_*Definitions :-*_ A section is not considered safe if there is some code that appears to be present between function boundaries (or) optimizes sections to place data at the end or beginning of a section (that contains no symbol).

Hi all, I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's safe point support looks like a good way to get code into all the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos points out that there's no way to emit code at safe points yet, and there are no loop safe points at all. So I'll be trying to implement them. Is

...de by checking if there's a >> gap >> between symbols, can we just assume a section with no gap is always >> "safe"? >> > Gaps could just be caused due to alignment, but the code may be safe, > which the compiler knows very well. > > > - "Safeness" is not an attribute of the section but of the symbol, I >> think. The symbol is "safe" if there's no direct reference to the symbol >> data. All references should go through relocations. A section may contain >> both "safe" and "unsafe" symb...

Hi Jeffrey, On 2009-06-22, at 01:49, Jeffrey Yasskin wrote: > I need to add thread-switching support to Unladen Swallow's JIT, and > LLVM's safe point support looks like a good way to get code into all > the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos > points out that there's no way to emit code at safe points yet, and >

Has anyone developed a version of do.call that is safe in the sense that it silently drops parameters that do not appear in the formals of the called function? This is useful when ... ends up being used in multiple further functions. e.g. f <- function(a, b) {a + b} do.call(f, list(a=1, b=2, c=3)) # Errors safe.call(f, list(a=1, b=2, c=3)) # Returns 3 If have quickly thrown together the

...gt;> gap >>> between symbols, can we just assume a section with no gap is always >>> "safe"? >>> >> Gaps could just be caused due to alignment, but the code may be safe, >> which the compiler knows very well. >> >> >> - "Safeness" is not an attribute of the section but of the symbol, I >>> think. The symbol is "safe" if there's no direct reference to the symbol >>> data. All references should go through relocations. A section may contain >>> both "safe" and "unsaf...

On Tue, Jun 23, 2009 at 4:18 AM, Gordon Henriksen <gordonhenriksen at me.com>wrote: > Hi Jeffrey, > On 2009-06-22, at 01:49, Jeffrey Yasskin wrote: > > I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's > safe point support looks like a good way to get code into all the right > places. However, >

On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > On 7/29/2013 11:24 AM, Nick Kledzik wrote: >> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF

Can anyone comment on the following results from running a test program we've writen for PostgreSQL? Should the following be thread-safe, either as themselves, or a different function we should be calling? Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe

From 8be8951015673d6279d7d49b0138645194317dc2 Mon Sep 17 00:00:00 2001 From: Shao Miller <shao.miller at yrdsb.edu.on.ca> Date: Wed, 9 Dec 2009 19:11:38 +0000 Subject: [PATCH] doc: document mBFT and "safe hook" --- doc/memdisk.txt | 40 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/doc/memdisk.txt b/doc/memdisk.txt

On 7/30/2013 5:43 PM, Nick Kledzik wrote: > On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker

Talin, do you identify safe-points in the current or proposed llvm scheme, and if so how, or are they implicit as being at all call sites (which begs the question what about leaves in the call tree, how does GC get started at all in that case). Peter Lawrence.

On Mon, Jul 18, 2011 at 11:00 AM, Peter Lawrence <peterl95124 at sbcglobal.net>wrote: > Talin, > do you identify safe-points in the current or proposed llvm > scheme, and if so how, > or are they implicit as being at all call sites (which begs the question > what about leaves > in the call tree, how does GC get started at all in that case). > > The LLVM

I have a failing test and bugpoint would be the perfect tool to help narrow it down. llc is the failing tool. It fails with one set of options and passes with another. I was hoping to use bugpoint like this: bugpoint -safe-llc -run-llc <testcase> -tool-args <failing args> -safe-tool-args <passing args> Unfortunately, this doesn't seem to be possible. According to the

Hi, I previously posted about using 32-bit X86 segmentation to harden SafeStack: http://lists.llvm.org/pipermail/llvm-dev/2016-May/100346.html That involves lowering the limits of the DS and ES segments that are used for ordinary data accesses while leaving the limit for SS, the stack segment, set to its maximum value. The safe stacks were clustered above the limits of DS and ES. Thus, by

Talin, how about having the front-end generate an llvm.safe.point () intrinsic call at the desired safe points, and having the addresses of the GC roots (at that point, can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, IIUC currently the GC roots are tagged, and all analysis and transform optimizations have to special case these tagged

Hello, For the Glasgow Haskell Compiler's backend, we would like to let LLVM know that certain loads are safe to execute speculatively and hence to hoist out of loops. At the moment, there doesn't seem to be a mechanism for doing so. There seem to be two ways of implementing this: either allow arbitrary instructions to be marked as safe and have Instruction::isSafeToSpeculativelyExecute

On 04/25/2014 10:12 AM, Eric Christopher wrote: > Hi Andrew, > > Replying in both places because this mail is a pretty good summary of > issues and so it's worth replying to... my apologies for continuing in > both places. Responding to LLVMDev - I for one had missed this part of the thread. > >> The only language aspect under discussion is integer division. Every