search for: safe

On 7/25/2013 3:56 PM, Rui Ueyama wrote: > I think I share the goal with you to make the foundation for better > dead-strip, so thank you for suggesting. I'm not sure if marking a section > as a whole as "safe" or "unsafe" 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 sectio...

I think I share the goal with you to make the foundation for better dead-strip, so thank you for suggesting. I'm not sure if marking a section as a whole as "safe" or "unsafe" 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 &...

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). A section is considered safe if symbols contained within the section have been associated with their appropriate siz...

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...

...nkar Easwaran <shankare at codeaurora.org>wrote: > On 7/25/2013 3:56 PM, Rui Ueyama wrote: > >> I think I share the goal with you to make the foundation for better >> dead-strip, so thank you for suggesting. I'm not sure if marking a section >> as a whole as "safe" or "unsafe" 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...

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 > there are no loop safe points at all. So I'll be trying to...

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)) # Retu...

...re at codeaurora.org>wrote: > >> On 7/25/2013 3:56 PM, Rui Ueyama wrote: >> >>> I think I share the goal with you to make the foundation for better >>> dead-strip, so thank you for suggesting. I'm not sure if marking a section >>> as a whole as "safe" or "unsafe" 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 &gt...

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, > 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...

...w ELF section. >> >From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in the .o file which the linker must process. >> >> For reference, with mach-o we just added a flag to the overall .o file that says all sections are "safe". The compiler always generates safe object files (unless there is inline code with non-local labels) and always sets the flag. Hand written assembly files did not have the flag by default, but savvy assembly programmers can set it. > We could set this flag for ELF too in the ELF header,...

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 index 8a308f1..254cb7c 100644 --- a/doc/memdisk.txt +++ b/doc/memdisk.txt @@ -9,6 +9,9 @@ disk and a (very small - 2K t...

...on. >>> >From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in the .o file which the linker must process. >>> >>> For reference, with mach-o we just added a flag to the overall .o file that says all sections are "safe". The compiler always generates safe object files (unless there is inline code with non-local labels) and always sets the flag. Hand written assembly files did not have the flag by default, but savvy assembly programmers can set it. >> We could set this flag for ELF too in the ELF hea...

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 linker has a feature where you can specify...

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 documentation both -tool-args and -safe-tool-args consume all remaining arguments so bugpoint would never see -safe-tool-args ab...

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...

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 t...

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 return true for...

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