similar to: How can I make llvm intrinsic functions declarations survive from optimizations.

Dear Sanjoy Das and community. I was tried to fix a bug in the pass InitAllocas from SAFECode. This is a function pass and will insert a prototype of 'llvm.memset.p0i8.i32' in the module at doInitialize() stage of the pass. But, this prototype will be eliminated by strip unused function optimization since there is no call on this function after doInitialization(). Therefore there will be

Hi Zhengyang, Do you mind sharing _why_ you need the intrinsic declarations to stay around? It is possible that there is a better way of solving your problem. Thanks! -- Sanjoy

Dear LLVM and SVA community: This is to brief you the progress of this week. I mainly focused on minor fixes this week. Following is what I finished this week. 1. Move the implementation of runOnModule of RegisterGlobalVar pass from .h back to .cpp file. 2. Introduce two new functions to register and unregister function prototypes on llvm.compiler.used. 3. Added two regression tests for

Hi, everyone This proposal covers the OpenProjects idea 'Port the Bigloo Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to output LLVM bytecode.' There is not a popular functional language frontend yet on LLVM. To my knowledge, this is mostly because LLVM is lack of runtime support for the functional language needs, and C foreign function interface calls are relatively

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Hi I am upgrading my clang fork from 5.0 to 6.0 and I am hit by this error: Access type node must be a valid scalar type %4 = load %"struct.Foo::p.test1::"*, %"struct.Foo::p.test1::"** %_param.addr, align 8, !tbaa !16 !16 = !{!15, !15, i64 0} !15 = !{!"p.test1::", !13, i64 0, !13, i64 8} It looks like !16 is referencing !15, which is a struct. !13 is !13 =

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Why does this need to be an intrinsic (as opposed to generic "unknown > function" to llvm)? > > Secondly, have you looked into a volatile store / load to an alloca? That > should work with PNaCl and WebAssembly. > > E.g. > > define i32 @blackbox(i32 %arg) { >

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: a

Hi folks, please check out our RFC: Supported Optimizations attribute https://docs.google.com/document/d/1s0n-JVaSNML1Z9SCZVg2bgisxswIJAK2Tp9DahucW10/edit?usp=sharing Pasting it here for the record: RFC: supported_optimizations attribute Piotr Padlewski - piotr.padlewski at gmail.com Krzysztof Pszeniczny - kpszeniczny at google.com December 2018 Introduction Sometimes a possible class of

First of all, I am really sorry about my time scheduling. I did not manage to upload my proposal at the last minutes before Google Summer of Code submission deadline. Could you kindly take the following revision as my final proposal? Abstraction --------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ (BBAC) [1] work. By adding information to the memory object’s

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, are the llvm.memset.p0i8.i32 and llvm.memset.p0i8.i64 intrinsics meant to be used for 32-bit and 64-bit architectures, respectively depending on the module's target datalayout? Or can I use any of them? If yes, why are there two functions? Sorry, if it's obvious, but the documentation wasn't that clear. Thanks and ciao, Mario

Hi all, I'm trying to prevent two things from happening: 1. Intrinsic memcpy calls of for example 16 bytes in the IR code being translated into movl commands in x86 assembly code, for example, this code: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %3, i8* getelementptr inbounds ([16 x i8]* @.str1, i32 0, i32 0), i32 16, i32 1, i1 false) translated into this x86 assembly movl

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048

Dear Community, As I keep you update with my progress by writing weekly report, this report is covering the information about how we are processing. For those who are interested in these weekly reports, please check [1]. In general, the progress of this project is in working order. Before the midterm, I have done the following works: 1. Finish the SAFECode llvm 3.7 portation. Currently it

Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],

Hi all, Consider the following example: define void @fn(i8* %buf) #0 { entry: %arrayidx = getelementptr i8* %buf, i64 18 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64 18, i32 1, i1 false) %arrayidx1 = getelementptr i8* %buf, i64 18 store i8 1, i8* %arrayidx1, align 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64 18, i32 1, i1 false)

> From: piotrekpad at gmail.com [mailto:piotrekpad at gmail.com] On Behalf Of Piotr Padlewski > Sent: den 16 oktober 2017 17:33 > > Hi David, > The patch didn't get a lot of attention, so probably others does not > consider it a huge deal. Anyway, if someone is willing to review this, I > can pursue rebasing it. Okay. We are interested in getting something akin to your

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast