[llvm-dev] help with clarifying function attributes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] help with clarifying function attributes

Tingyuan LIANG via llvm-dev
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 <[hidden email]> wrote:
Send llvm-dev mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: llvm-dev <[hidden email]>
Subject: [llvm-dev] Get begin/end of section of lld/wasm
Message-ID: <[hidden email]>
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 <[hidden email]>
To: Viktor Was BSc <[hidden email]>
Cc: LLVM Development List <[hidden email]>
Subject: Re: [llvm-dev] Opt plugin linkage
Message-ID:
        <CAHe691Fowto-=grkRCtSeP2FgX=[hidden email]>
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:[hidden email]
> <[hidden email]>] *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"<[hidden email]>
> <[hidden email]>;
>
> *Date: * Wed, Apr 17, 2019 04:35 AM
>
> *To: * "Viktor Was BSc"<[hidden email]>
> <[hidden email]>; "llvm-dev"<[hidden email]>
> <[hidden email]>;
>
> *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"<[hidden email]>
> <[hidden email]>;
>
> *Date: * Wed, Apr 17, 2019 03:09 AM
>
> *To: * "llvm-dev"<[hidden email]> <[hidden email]>;
>
> *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 <
> [hidden email]> 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 [hidden email]://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> 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 <[hidden email]>
To: Tom Stellard <[hidden email]>
Cc: llvm-dev <[hidden email]>, Release-testers
        <[hidden email]>, cfe-dev <[hidden email]>,
        "openmp-dev \([hidden email]\)"
        <[hidden email]>, LLDB Dev <[hidden email]>
Subject: Re: [llvm-dev] [Release-testers] LLVM 7.1.0-final has been
        tagged
Message-ID:
        <[hidden email]>
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 <
[hidden email]> wrote:

> Hi,
>
> I've just tagged LLVM 7.1.0-final.  Testers, please upload the final
> binaries.
>
> Thanks,
> Tom
> _______________________________________________
> Release-testers mailing list
> [hidden email]
> 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 <[hidden email]>
To: "=?utf-8?Q?llvm-dev=40lists.llvm.org?=" <[hidden email]>,
        "=?utf-8?Q?tstellar=40redhat.com?=" <[hidden email]>,  Arsenault,
        Matthew <[hidden email]>
Subject: Re: [llvm-dev] Disable combining of loads and stores in
        instcombine
Message-ID: <b56ad594-d89e-4f65-900c-47834f2d5cf1@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 <[hidden email]>, 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 <[hidden email]> on behalf of llvm-dev <[hidden email]>
> Reply-To: Neil Ryan <[hidden email]>
> Date: Wednesday, April 17, 2019 at 9:28 PM
> To: llvm-dev <[hidden email]>, "[hidden email]" <[hidden email]>
> 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 <[hidden email]>, 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
> > > [hidden email]
> > > 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 <[hidden email]>
To: Fāng-ruì Sòng <[hidden email]>
Cc: LLVM Developers Mailing List <[hidden email]>, James
        Henderson <[hidden email]>
Subject: Re: [llvm-dev] Accept --long-option but not -long-option for
        llvm binary utilities
Message-ID:
        <CACs=ty+EcWbrcpNep_g_RMxfLEyPymSjR65+qV3WnrZX380=[hidden email]>
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 <
[hidden email]> 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
> [hidden email]
> 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 <[hidden email]>
To: llvm-dev <[hidden email]>
Subject: [llvm-dev] Mentors and projects needed for Season of Docs
Message-ID: <[hidden email]>
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


------------------------------

End of llvm-dev Digest, Vol 178, Issue 56
*****************************************

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] help with clarifying function attributes

Tingyuan LIANG via llvm-dev
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

[hidden email]

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

ISC19.pdf (604K) Download Attachment
signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] help with clarifying function attributes

Tingyuan LIANG via llvm-dev
In reply to this post by Tingyuan LIANG via llvm-dev
Hi Gracia,

(Same email as before without attached pdf but with a link to it.)

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:
  speculatable
  readnone
  readonly
  readonly
  argmemonly
  inaccessiblememonly
  inaccessiblemem_or_argmemonly

I also linked our ISC'19 paper [5] below. Section 3 describes various
attributes in LLVM-IR, including the ones above (in 3.4.2).

[5] https://github.com/jdoerfert/PETOSPA/blob/master/ISC19.pdf

Cheers,
  Johannes

> Any replies are appreciated.
>
> Regards,
> Gracia

--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

[hidden email]

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

signature.asc (235 bytes) Download Attachment