[llvm-dev] help with clarifying function attributes
Shiyao Ge via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 19 14:55:59 PDT 2019
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>
More information about the llvm-dev
mailing list