Shiyao Ge via llvm-dev
2019-Apr-19 21:55 UTC
[llvm-dev] help with clarifying function attributes
Hi all, I read about the lib function attributes deduction lately and got confused about the OnlyAccessesInaccessibleMem function atrribute. The explaining text is "function may only access memory that is either inaccessible from the IR or pointed to by its argument". So what kind of function can be annotated with this attribute, functions which malloc heap memory and free it within the same scope? Besides, I spot the attribute onlyaccessesargmem is used in AA to determine ModRef behavior of functions and there is another ModRef behavior named as OnlyReadArgMem, does it means we could have another function attribute added to serve the purpose? Any replies are appreciated. Regards, Gracia On Fri, Apr 19, 2019, 11:58 via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Send llvm-dev mailing list submissions to > llvm-dev at lists.llvm.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > or, via email, send a message with subject or body 'help' to > llvm-dev-request at lists.llvm.org > > You can reach the person managing the list at > llvm-dev-owner at lists.llvm.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of llvm-dev digest..." > > > Today's Topics: > > 1. Get begin/end of section of lld/wasm (Carlo Kok via llvm-dev) > 2. Re: Opt plugin linkage (Philip Pfaffe via llvm-dev) > 3. Re: [Release-testers] LLVM 7.1.0-final has been tagged > (Brian Cain via llvm-dev) > 4. Re: Disable combining of loads and stores in instcombine > (Neil Ryan via llvm-dev) > 5. Re: Accept --long-option but not -long-option for llvm binary > utilities (Reid Kleckner via llvm-dev) > 6. Mentors and projects needed for Season of Docs > (Tanya Lattner via llvm-dev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Apr 2019 03:30:39 -0400 > From: Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [llvm-dev] Get begin/end of section of lld/wasm > Message-ID: <becccfe3-8c91-4f27-99a0-289057b194f0 at www.fastmail.com> > Content-Type: text/plain > > Hi, > > > when linking with lld/wasm with a symbol like: > > @_typeinfo__rtti_te_Module6_d_Test = private constant i8* bitcast > (@_rtti_te_Module6_d_Test to i8*), section "ELRTTLRR", align 4 > > > How do I get the start and end of the ELRTTLRR section? LLD doesn't seem > to emit that info, nor does it define a __start_ELRTTLRR/__stop_ELRTTLRR > section? > > > ------------------------------ > > Message: 2 > Date: Fri, 19 Apr 2019 12:13:10 +0200 > From: Philip Pfaffe via llvm-dev <llvm-dev at lists.llvm.org> > To: Viktor Was BSc <gs15m015 at technikum-wien.at> > Cc: LLVM Development List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Opt plugin linkage > Message-ID: > <CAHe691Fowto-=grkRCtSeP2FgX> NvyU_tFy44s54+106PtipJA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Viktor, > > > Though, I feel like this should also be possible with statically linking > > the ExecutionEngine into the plugin shared object. > > > Unfortunately it won't. In general, you don't link any LLVM libraries into > opt plugins because opt already has all the symbols you need. If you were > to link in the libraries, all sorts of problems arise, most of them because > we have lot's of global state everywhere. With dynamic linking, most of the > problems can be avoided because the dependencies won't be loaded twice. > > Cheers, > Philip > > > I don't quite understand how the concrete Interpreter/MCJIT linking via > > llvm/ExecutionEngine/Interpreter.h and llvm/ExecutionEngine/MCJIT.h > works. > > So far I was only using ExecutionEngine.h without Interpreter or MCJIT, > so > > that could have been the problem why static linking didn't work. > > > > After playing around with Zhangs solution I've found out that I get the > > same undefined symbol to llvm::EngineBuilder error when omitting the > MCJIT > > header and lib (since I actually only need an interpreter), my guess is > > that this is due to Interpreter.h missing the getenv trick used in > MCJIT.h > > to prevent it being optimized away by the compiler? I might take a closer > > look at this at some point, right now I'm just happy to finally be able > to > > work on my opt pass. > > > > > > Thanks, > > > > Viktor > > > > > > On 4/18/19 7:38 PM, John Brawn wrote: > > > > The fundamental problem here is that opt doesn’t use ExecutionEngine > > (because it has no need to), so trying > > > > to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for > > that matter) in an opt plugin isn’t > > > > going to work. > > > > > > > > The solution I’d go with would be to build llvm with shared libraries > (use > > –DBUILD_SHARED_LIBS=ON on the > > > > cmake command) then link the plugin against ExecutionEngine. That > > shouldn’t require any changes anywhere > > > > (when I gave it a quick try it seemed to work). > > > > > > > > John > > > > > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org > > <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Zhang via llvm-dev > > *Sent:* 16 April 2019 22:04 > > *To:* Viktor Was BSc; llvm-dev > > *Subject:* Re: [llvm-dev] Opt plugin linkage > > > > > > > > Just another follow-up, seems like ExecutionEngine is still not usable > > without editing CMakeLists, on my setup I had to edit CMakeLists.txt as > > well to get the example working. > > > > Below is the modifications I made: > > > > > > > > Modified Hello.cpp for testing: > > > > ``` > > > > bool runOnFunction(Function &F) override { > > > > ++HelloCounter; > > > > std::string errStr; > > > > EngineBuilder eb; > > > > eb.setErrorStr(&errStr); > > > > eb.setEngineKind(EngineKind::Kind::JIT); > > > > ExecutionEngine* ee=eb.create(); > > > > errs()<<"ExecutionEngine:"<<ee<<" Error:"<<errStr<<"\n"; > > > > delete ee; > > > > errs() << "Hello: "; > > > > errs().write_escaped(F.getName()) << '\n'; > > > > return false; > > > > } > > > > ``` > > > > > > > > Modified opt's CMakeLists.txt: > > > > > > > > ``` > > > > set(LLVM_LINK_COMPONENTS > > > > ${LLVM_TARGETS_TO_BUILD} > > > > AggressiveInstCombine > > > > Analysis > > > > BitWriter > > > > CodeGen > > > > Core > > > > MC > > > > MCJIT > > > > Object > > > > OrcJIT > > > > Interpreter > > > > RuntimeDyld > > > > Coroutines > > > > IPO > > > > IRReader > > > > InstCombine > > > > Instrumentation > > > > MC > > > > ObjCARCOpts > > > > ScalarOpts > > > > Support > > > > Target > > > > TransformUtils > > > > Vectorize > > > > Passes > > > > ExecutionEngine > > > > ) > > > > > > > > # Support plugins. > > > > set(LLVM_NO_DEAD_STRIP 1) > > > > > > > > add_llvm_tool(opt > > > > AnalysisWrappers.cpp > > > > BreakpointPrinter.cpp > > > > Debugify.cpp > > > > GraphPrinters.cpp > > > > NewPMDriver.cpp > > > > PassPrinters.cpp > > > > PrintSCC.cpp > > > > opt.cpp > > > > > > > > DEPENDS > > > > intrinsics_gen > > > > ) > > > > export_executable_symbols(opt) > > > > > > > > if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS) > > > > target_link_libraries(opt PRIVATE Polly) > > > > endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS) > > > > target_link_libraries(opt PUBLIC LLVMExecutionEngine) > > > > > > > > ``` > > > > > > > > Modified opt's LLVMBuild.txt: > > > > > > > > ``` > > > > ;===- ./tools/opt/LLVMBuild.txt --------------------------------*- Conf > > -*--===; > > > > ; > > > > ; The LLVM Compiler Infrastructure > > > > ; > > > > ; This file is distributed under the University of Illinois Open Source > > > > ; License. See LICENSE.TXT for details. > > > > ; > > > > > > > ;===------------------------------------------------------------------------===; > > > > ; > > > > ; This is an LLVMBuild description file for the components in this > > subdirectory. > > > > ; > > > > ; For more information on the LLVMBuild system, please see: > > > > ; > > > > ; http://llvm.org/docs/LLVMBuild.html > > > > ; > > > > > > > ;===------------------------------------------------------------------------===; > > > > > > > > [component_0] > > > > type = Tool > > > > name = opt > > > > parent = Tools > > > > required_libraries > > > > AsmParser > > > > BitReader > > > > BitWriter > > > > CodeGen > > > > IRReader > > > > IPO > > > > Instrumentation > > > > Scalar > > > > ObjCARC > > > > Passes > > > > ExecutionEngine > > > > Interpreter > > > > MCJIT > > > > Native > > > > NativeCodeGen > > > > all-targets > > > > > > > > ``` > > > > > > > > On top of that I also added these lines to the beginning of main function > > in opt.cpp to force linking ExecutionEngine: > > > > > > > > ``` > > > > if(argc==-1){ > > > > EngineBuilder eb; > > > > ExecutionEngine* ee=eb.create(); > > > > delete ee; > > > > } > > > > ``` > > > > > > > > as well as force linking MCJIT and Interpreter by including headers in > opt: > > > > > > > > ``` > > > > #include "llvm/ExecutionEngine/ExecutionEngine.h" > > > > #include "llvm/ExecutionEngine/Interpreter.h" > > > > #include "llvm/ExecutionEngine/MCJIT.h" > > > > ``` > > > > > > > > Moving cl::parseCommandLineOptions doesn't seem to be related to the > > issue, my previous assumption was wrong. > > > > > > > > Those modifications works at least on my setup with the following output: > > > > > > > > ``` > > > > λ : >>> bin/opt -load lib/LLVMHello.dylib hw.ll -hello > > > > WARNING: You're attempting to print out a bitcode file. > > > > This is inadvisable as it may cause display problems. If > > > > you REALLY want to taste LLVM bitcode first-hand, you > > > > can force output with the `-f' option. > > > > > > > > Assertion failed: (M && "Module is null?"), function Init, file > > > /Users/naville/Development/Hikari/lib/ExecutionEngine/ExecutionEngine.cpp, > > line 80. > > > > > > > > ``` > > > > > > > > Which is due to i didn't initialize the EEBuilder properly, but at least > > the pass now loads and executes properly > > > > > > > > > > > > Zhang > > > > > > > > > > > > > > > > > > > > > > > > ------------------ Original ------------------ > > > > *From: * "Zhang via llvm-dev"<llvm-dev at lists.llvm.org> > > <llvm-dev at lists.llvm.org>; > > > > *Date: * Wed, Apr 17, 2019 04:35 AM > > > > *To: * "Viktor Was BSc"<gs15m015 at technikum-wien.at> > > <gs15m015 at technikum-wien.at>; "llvm-dev"<llvm-dev at lists.llvm.org> > > <llvm-dev at lists.llvm.org>; > > > > *Subject: * Re: [llvm-dev] Opt plugin linkage > > > > > > > > Hey: > > > > I spent sometime debugging this, it seems like editing > > ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, > > > > "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the > > beginning of main() solved it for me. I'm not sure if this is a bug on > LLVM > > side > > > > > > > > > > > > Zhang > > > > > > > > > > > > ------------------ Original ------------------ > > > > *From: * "Viktor Was BSc via llvm-dev"<llvm-dev at lists.llvm.org> > > <llvm-dev at lists.llvm.org>; > > > > *Date: * Wed, Apr 17, 2019 03:09 AM > > > > *To: * "llvm-dev"<llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>; > > > > *Subject: * Re: [llvm-dev] Opt plugin linkage > > > > > > > > How come the hello pass example is so totally useless as a starting > point? > > Why is this not using any library/compontent which could conflict with > opt > > or clang and showing how to handle this? I have no clue as to how I have > to > > setup llvm to get this to work or why it doesn't work in the first place > > with the setup described in "Getting started" and "writing an llvm pass" > > pages etc. > > > > Also there is basically no documentation for the custom cmake commands. > > > > Can please somebody help me with this issue? How do I get dynamically > > loaded llvm pass plugins to work? Am I the only one ever having this > issue? > > > > Thanks > > > > Viktor > > > > On Apr 16, 2019, at 05:38, Viktor Was BSc via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > I have a dynamically loaded llvm pass built in-tree with ninja (generated > > with cmake, basically a copy of the hallo pass plugin, linux, llvm/clang > > version 6.0.1). > > > > It uses the ExecutionEngine. > > > > Building it without linking against LLVMExecutionEngine library results > in > > an undefined symbol to the vtable of the EngineBuilder when loaded to > opt. > > Linking the plugin with LLVMExecutionEngine results in the pass simply > not > > being executable with giving "opt: Unkown command line argument > > '-passArg'." > > > > For a minimal example add set(LLVM_LINK_COMPONENTS Core) to the > > CMakeLists.txt of the Hello llvm pass. > > > > There is no error or warning at any point when linking or loading a > plugin > > linked against some libs. > > > > How do I find out which llvm libs I can't link with a dynamically loaded > > plugin? > > > > How can I use the EngineBuilder in my plugin with proper symbol > resolution? > > > > For reproductivity: > > > > cmake -G "Sublime Text 2 - Ninja" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON > > -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON -DLLVM_BUILD_TESTS=ON > > -DLLVM_BUILD_EXAMPLES=ON -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" > > -DLLVM_TOOL_CLANG_BUILD=ON -DLLVM_TOOL_CLANG_TOOLS_EXTRA=ON > > -DLLVM_OPTIMIZED_TABLEGEN=ON -DCLANG_BUILD_EXAMPLES=ON > > -DCLANG_PLUGIN_SUPPORT=ON > > > > Hope someone can help me out. > > > > Viktor > > > > ------------------------------ > > > > > > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps:// > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/617ee6a5/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Fri, 19 Apr 2019 07:43:25 -0500 > From: Brian Cain via llvm-dev <llvm-dev at lists.llvm.org> > To: Tom Stellard <tstellar at redhat.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org>, Release-testers > <release-testers at lists.llvm.org>, cfe-dev <cfe-dev at lists.llvm.org > >, > "openmp-dev \(openmp-dev at lists.llvm.org\)" > <openmp-dev at lists.llvm.org>, LLDB Dev <lldb-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [Release-testers] LLVM 7.1.0-final has been > tagged > Message-ID: > < > CAEWpfG8+42peP9S+xdT+xYJ3kULFqHYVka4gfjKMws5thrG9zg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Uploaded Ubuntu 14 and SLES 11 x86 binaries. > > 8a5d880f3ed2b10d80660d1029b0c958878c3cb7 > clang+llvm-7.1.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz > 81f5b08cc8cac534e4a7405de46a2ef28d978477 > clang+llvm-7.1.0-x86_64-linux-sles11.3.tar.xz > > > On Thu, Apr 11, 2019 at 7:00 PM Tom Stellard via Release-testers < > release-testers at lists.llvm.org> wrote: > > > Hi, > > > > I've just tagged LLVM 7.1.0-final. Testers, please upload the final > > binaries. > > > > Thanks, > > Tom > > _______________________________________________ > > Release-testers mailing list > > Release-testers at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > > > > > -- > -Brian > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/fb2befb2/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Apr 2019 12:58:42 -0700 > From: Neil Ryan via llvm-dev <llvm-dev at lists.llvm.org> > To: "=?utf-8?Q?llvm-dev=40lists.llvm.org?=" <llvm-dev at lists.llvm.org>, > "=?utf-8?Q?tstellar=40redhat.com?=" <tstellar at redhat.com>, > Arsenault, > Matthew <Matthew.Arsenault at amd.com> > Subject: Re: [llvm-dev] Disable combining of loads and stores in > instcombine > Message-ID: <b56ad594-d89e-4f65-900c-47834f2d5cf1 at Spark> > Content-Type: text/plain; charset="utf-8" > > IIRC it’s not strictly possible to determine what array a load/store is > based on. I don’t believe the decomposition is always possible, as > information is lost when accesses are combined. > > Neil > On Apr 17, 2019, 12:31 PM -0700, Arsenault, Matthew < > Matthew.Arsenault at amd.com>, wrote: > > This is really a codegen problem. You can decompose the load/store > however you like in the backend. InstCombine should still combine the loads > as a canonicalization. > > > > -Matt > > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of llvm-dev < > llvm-dev at lists.llvm.org> > > Reply-To: Neil Ryan <neilryan at cs.washington.edu> > > Date: Wednesday, April 17, 2019 at 9:28 PM > > To: llvm-dev <llvm-dev at lists.llvm.org>, "tstellar at redhat.com" < > tstellar at redhat.com> > > Subject: Re: [llvm-dev] Disable combining of loads and stores in > instcombine > > > > I’m writing a pass for some custom hardware — we’d like to split arrays > across hardware elements; this doesn’t work if consecutive writes to > characters get combined to a word. > > On Apr 16, 2019, 8:17 PM -0700, Tom Stellard <tstellar at redhat.com>, > wrote: > > > > > On 04/16/2019 11:38 AM, Neil Ryan via llvm-dev wrote: > > > > > > > LLVM's optimizer combines stores to consecutive characters into a > write of a single word. For instance, if I have char A[4] and I write some > static value to each element, these writes would be combined into a single > 32-bit word write. I found this thread < > http://llvm.1065342.n5.nabble.com/disabling-combining-load-stores-in-optimizer-td37560.html> > from 2009 -- it seems like it wasn't possible then. Has anything changed > since? > > > > > > Why do you want to disable this optimization? > > > > > > -Tom > > > > > > > > > > > > > Neil > > > > > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > llvm-dev at lists.llvm.org > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20190418/440559e2/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Fri, 19 Apr 2019 11:13:26 -0700 > From: Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> > To: Fāng-ruì Sòng <maskray at google.com> > Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>, James > Henderson <jh7370 at my.bristol.ac.uk> > Subject: Re: [llvm-dev] Accept --long-option but not -long-option for > llvm binary utilities > Message-ID: > <CACs=ty+EcWbrcpNep_g_RMxfLEyPymSjR65+qV3WnrZX380> 2w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Are you proposing to make this the new style across all LLVM utilities? > That seems needlessly disruptive. There are plenty of scripts that call > `opt` and `llc` directly with single dash long options, regardless of how > much we claim that they are not public facing, and are only developer > tools. > > If you want to add a flag to ParseCommandLineOptions so that individual > LLVM tools can opt into the new behavior gradually, I think that would be > reasonable. > > On Mon, Apr 15, 2019 at 11:41 PM Fāng-ruì Sòng via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Many llvm utilities use cl::ParseCommandLineOptions() > > (include/Support/CommandLine.h) to parse command line options. The cl > > library accepts both -long-option and --long-option forms, with the > single > > dash form (-long-option) being more popular. > > > > We also have many binary utilities (llvm-objcopy llvm-objdump > llvm-readobj > > llvm-size ...) whose names reflect what they imitate. For compatibility > > with GNU binutils (and some Unix utilities transitively), these utilities > > accept many short options. People who use llvm utilities as replacement > of > > GNU binutils may use the grouped option syntax (POSIX Utility > Conventions), > > e.g. -Sx => -S -x, -Wd => -W -d, -sj.text => -s -j.text > > > > The problem is, grouped short options don't play well with -long-option. > > Sometimes there can be ambiguity. The issue is more prominent if the > short > > option accepts an argument. > > > > An approach to prevent the ambiguity is to just disallow -long-option. > > In D60439, I plan to make llvm-objcopy accept --long-option but not > > -long-option. > > It will make its command line option parsing behave more like GNU objcopy > > and less like a regular llvm utility. What do people think of the > > divergence? > > > > Further, can we make similar changes to other llvm binary utilities > (their > > names give people the expectation), especially those with many short > > options such as llvm-objdump and llvm-readobj? llvm-readobj behaves like > > GNU readelf if you name it "llvm-readelf". (I don't suggest disallowing > > -long-option for utilities other than binutils) > > > > (Note, llvm-objcopy is a new member of the family and it uses tablegen > > based include/llvm/Option/Opton.h, instead of cl:: as other utilities > do.) > > > > > > > > -- > > 宋方睿 > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/67914ec2/attachment-0001.html > > > > ------------------------------ > > Message: 6 > Date: Fri, 19 Apr 2019 11:16:25 -0700 > From: Tanya Lattner via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [llvm-dev] Mentors and projects needed for Season of Docs > Message-ID: <E8AF8175-56D3-4690-A811-972604AA9665 at llvm.org> > Content-Type: text/plain; charset="utf-8" > > LLVM Developers, > > Google has a new program called Season of Docs < > https://developers.google.com/season-of-docs/>. To summarize, this > program brings together open source communities and technical writers to > the benefit of both. Open source communities are paired with technical > writers on technical writing projects proposed by the open source > community. > > As good documentation is key to getting new developers involved with the > LLVM Project and also helping existing developers, I feel it would be > beneficial if LLVM participated in this program. > > Here is where we need your help! For our application, we need a list of > open projects that are a good fit for technical writers. Here is the > description of what the open projects proposals consist of: > https://developers.google.com/season-of-docs/docs/project-ideas < > https://developers.google.com/season-of-docs/docs/project-ideas> > Second, we need mentors to work with the technical writers as they work on > the projects. Even if you don’t want to be involved in drafting the ideas, > the technical writers will need mentors to help guide them and answer LLVM > related questions. > > If you have an idea for a project, please send me your outline. We are > currently creating a web page for our application. Or if you just are > interested in being a mentor (no commitment until you see the list of > projects), then send me a quick email. The deadline for the application is > April 23, 2019 at 20:00 UTC (so not much time). > > If you have questions, please let me know. As this program is new, we are > all trying to figure it out :) > > Thank you, > Tanya Lattner > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/5c77b929/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > llvm-dev mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > ------------------------------ > > End of llvm-dev Digest, Vol 178, Issue 56 > ***************************************** >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/2c105d16/attachment-0001.html>
Doerfert, Johannes via llvm-dev
2019-Apr-20 01:50 UTC
[llvm-dev] help with clarifying function attributes
Hi Gracia, On 04/19, Shiyao Ge via llvm-dev wrote:> I read about the lib function attributes deduction lately and got confused > about the OnlyAccessesInaccessibleMem function atrribute. The explaining > text is "function may only access memory that is either inaccessible from > the IR or pointed to by its argument".That is the definition of "inaccessiblemem_or_argmemonly" and not "inaccessiblememonly" (function attribute spelling, see [1]) which would correspond to OnlyAccessesInaccessibleMem. I'll assume the latter in this mail, which has the same meaning as the former but without the argument part (="or pointed to by its arguments"). [1] http://llvm.org/docs/LangRef.html#function-attributes> So what kind of function can be annotated with this attribute, > functions which malloc heap memory and free it within the same scope?Short answer: Yes, we probably could but do not do it right now. Longer answer below. Also consider the use case of (known) function defined in another translation unit (=module). They could then even work on some global state, e.g., a global variable, if it never "leaks" out of the other scope. Right now, if I remember correctly, we actually do not "deduce" "inaccessiblememonly", nor do we propagate it. For the proposed Attributor framework [2] there is a patch [3] to propagate it if only "inaccessiblememonly" functions are called. There is a proposed GSoC project [4] which could bring this attribute to C headers, though that is another story ;) [2] https://reviews.llvm.org/D59918 [3] https://reviews.llvm.org/D60077 [4] http://llvm.org/OpenProjects.html#header-generation Longer answer for the malloc-free scenario you mentioned: The answer depends on how you interpret the malloc and free semantic. In your scenario, and from the callers perspective, the memory accesses are not observable. If we assume alloc (and the implicit free at the return) it would not be distinguishable from readnone, so readnone would be appropriate. I'd argue the same would hold if (1) malloc and free would never fail and (2) be perfectly opposing functions, meaning the global state after a malloc-free sequence is the same as before. Since malloc does however modify some global state and there is no guarantee that it will go back to the way it was after free, we cannot deduce readnone here. It is however reasonable to assume that the state used to orchestrate malloc and free (and friends) is only accessible by these functions. Since that is the only state malloc/free/... access, they can be marked as "inaccessiblememonly". Using the fact that malloc also returns a no-alias pointer, and assuming it doesn't escape in the scenario you describe, we can mark the function using only malloc, free, and the allocated memory as "inaccessiblememonly".> Besides, I spot the attribute onlyaccessesargmem is used in AA to determine > ModRef behavior of functions and there is another ModRef behavior named as > OnlyReadArgMem, does it means we could have another function attribute > added to serve the purpose?Already existing, see [1] above for all function attributes. You might like: readnone readonly readonly argmemonly inaccessiblememonly inaccessiblemem_or_argmemonly I also attached our ISC'19 paper to this mail. Section 3 describes various attributes in LLVM-IR, including the ones above (in 3.4.2). Cheers, Johannes> Any replies are appreciated. > > Regards, > Gracia-- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60439, USA jdoerfert at anl.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: ISC19.pdf Type: application/pdf Size: 451780 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190420/fee224b0/attachment-0001.pdf> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190420/fee224b0/attachment-0001.sig>