similar to: Interprocedural AA

Hi Alberto, I have not used this myself, but I think you should be able to visit your Instruction ‘users()’. I think the name this function was given is a bit confusing, but this returns an iterator range you can iterate through to find instructions that depend on a given one. Similarly, you have the function ‘uses()’ that can be used to traverse down the DAG when instructions are still on SSA

Dear LLVM devs, My GSoC project this year is about alias analysis, and I wrote a short article describing what I've done during the summer: https://github.com/grievejia/GSoC2016/raw/master/writeup.pdf In the report you can find an overview of what the current status of CFL-AA. There are also some numbers in the end, but please take those numbers with a grain of salt as they were rather

dear LLVMers, I am trying to use some of the LLVM alias analyses, and I would like to check two things with you: is scev-aa being maintained in LLVM 3.7? Second question: I run cfl-aa, and I got a very small number of pointer disambiguation (no alias) with it. My results for SPEC CINT 2006 follow below. Is this low number of no alias responses something to be excepted? Below the results that I

Hi David, I am the one who's responsible for CFLAA's refactoring in the summer. I've sent out another email on llvm-dev, and you can find more about my work in my GSoC final report. I think it is fantastic that you have done such an interesting work. I'll definitely try to help getting the code reviewed and merged in the current. After a quick glance at your patch, it seems

Hi folks, We would like to add SeaHorn <http://seahorn.github.io/> and Crab-llvm <https://github.com/seahorn/crab-llvm> to the list of LLVM's users on http://llvm.org/Users.html under Open Source Projects. The descriptions would be: 1. SeaHorn | An Algorithmic Logic-Based Reasoning Framework. 2. Crab-llvm | A static analyzer based on abstract interpretation for LLVM. I attach a

Hello, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

Dear all, I want to implement a pass that provides some kind of data flow integrity similar to Write Integrity Testing (https://www.doc.ic.ac.uk/~cristic/papers/wit-sp-ieee-08.pdf). This approach statically determines for each memory write the (conservative, overapproximated) points-to set of locations that can be written by the instruction. Further, it instruments the memory write instruction

Hi Ma, how can I transform the llvm.memcpy into data move loop IR and eliminate > the bitcast instruction ? > I'm not sure why you are concerned about memcpy and bitcasts, but if you call MCpyInst->getSource() and MCpyInst->getDest() it will look through casts and give you the 'true' source/destination. If you want to get rid of memcpy altogether, you can take a look

Hello List, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

Dear Developers, I am a Master's student at the ECE department of the University of Florida, USA.​​ For my research project, supervised by Prof. Mark Tehranipoor<http://tehranipoor.ece.ufl.edu/> and Prof. Farimah Farahmandi<http://farimah.ece.ufl.edu/>, I need to use Clang LLVM DataflowSanitizer library in KLEE. However, I have faced some difficulties (explained below) while

Hi Craig Thank you very much ！ 2018-01-30 16:11 GMT+08:00 Craig Topper <craig.topper at gmail.com>: > The pointers must always be i8* the alignment is independent and is > controlled by the attributes on the arguments in the call to memcpy. > > ~Craig > > On Mon, Jan 29, 2018 at 11:45 PM, ma jun <jun.parser at gmail.com> wrote: > >> Hi >> >>

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

Hi, I am looking for some flow-sensitive (context-insensitive) alias analysis algorithm implemented in LLVM. (I use LLVM 3.9, hope to switch to 4.0 soon.) As far as I know, none of the built-in analysis (basicAA, globals-modref, andersAA, etc.) is intended to be flow-sensitive. So I searched and came across these two 1. https://github.com/unsw-corg/SVF by Yulei Sui (for LLVM 3.8) 2.

On 31 Jan 2018, at 17:36, Jakub (Kuba) Kuderski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > If you want to get rid of memcpy altogether, you can take a look at this pass: https://github.com/seahorn/seahorn/blob/master/lib/Transforms/Scalar/PromoteMemcpy.cc . There are at least four different places in LLVM where memcpy intrinsics are expanded to either sequences of

Hello, I’m trying to port a project up to 4.0 and I’m seeing the following error: In file included from /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode

Perhaps by "value" you mean points-to set? Either way, flow-sensitivity can only give you more precise -- but still not necessarily exact -- answers. Yours, Andrey === Compiler Architect NXP On Fri, Mar 10, 2017 at 6:39 PM, Flamedoge via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > For a given argument of a call instruction in the cfg: Where does the > value of

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

On Sat, Jul 15, 2017 at 5:35 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>> >>>> Thank you all for your replies. >>>> So here seems to be an agreement that the documentation for >>>> PartialAlias is incorrect. >>>>

# Front matter # First, I want to emphasize that this is not a short-term plan. This is a long-term plan. When I was looking at refactoring the existing Alias Analysis infrastructure in LLVM in ways that would break stateful AA, Hal Finkel asked me to figure out how things would work with the new pass manager and make sure that was sane. This plan assumes the new pass manager. There is nothing

Oops thanks for the reminder. I did use another email address and am terribly sorry for it. Let me just post the link: https://docs.google.com/document/d/1Kvepb-v5Ta8ug_lLK1kZeexPNlpvj62K5iIF0fMuLyM/edit?usp=sharing On 03/25/2016 11:44 AM, John Criswell wrote: > Dear Jia, > > I don't see your proposal in the system. What is the title of your > proposal, and under what email