<div dir="auto">Hi all, <div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Any replies are appreciated.</div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Gracia</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2019, 11:58 via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send llvm-dev mailing list submissions to<br>
        <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:llvm-dev-request@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:llvm-dev-owner@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of llvm-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Get begin/end of section of lld/wasm (Carlo Kok via llvm-dev)<br>
   2. Re: Opt plugin linkage (Philip Pfaffe via llvm-dev)<br>
   3. Re: [Release-testers] LLVM 7.1.0-final has been tagged<br>
      (Brian Cain via llvm-dev)<br>
   4. Re: Disable combining of loads and stores in instcombine<br>
      (Neil Ryan via llvm-dev)<br>
   5. Re: Accept --long-option but not -long-option for llvm binary<br>
      utilities (Reid Kleckner via llvm-dev)<br>
   6. Mentors and projects needed for Season of Docs<br>
      (Tanya Lattner via llvm-dev)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 19 Apr 2019 03:30:39 -0400<br>
From: Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
Subject: [llvm-dev] Get begin/end of section of lld/wasm<br>
Message-ID: <<a href="mailto:becccfe3-8c91-4f27-99a0-289057b194f0@www.fastmail.com" target="_blank" rel="noreferrer">becccfe3-8c91-4f27-99a0-289057b194f0@www.fastmail.com</a>><br>
Content-Type: text/plain<br>
<br>
Hi,<br>
<br>
<br>
when linking with lld/wasm with a symbol like:<br>
<br>
@_typeinfo__rtti_te_Module6_d_Test = private constant i8* bitcast (@_rtti_te_Module6_d_Test to i8*), section "ELRTTLRR", align 4<br>
<br>
<br>
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?<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 19 Apr 2019 12:13:10 +0200<br>
From: Philip Pfaffe via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: Viktor Was BSc <<a href="mailto:gs15m015@technikum-wien.at" target="_blank" rel="noreferrer">gs15m015@technikum-wien.at</a>><br>
Cc: LLVM Development List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] Opt plugin linkage<br>
Message-ID:<br>
        <CAHe691Fowto-=grkRCtSeP2FgX=<a href="mailto:NvyU_tFy44s54%2B106PtipJA@mail.gmail.com" target="_blank" rel="noreferrer">NvyU_tFy44s54+106PtipJA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Viktor,<br>
<br>
> Though, I feel like this should also be possible with statically linking<br>
> the ExecutionEngine into the plugin shared object.<br>
><br>
Unfortunately it won't. In general, you don't link any LLVM libraries into<br>
opt plugins because opt already has all the symbols you need. If you were<br>
to link in the libraries, all sorts of problems arise, most of them because<br>
we have lot's of global state everywhere. With dynamic linking, most of the<br>
problems can be avoided because the dependencies won't be loaded twice.<br>
<br>
Cheers,<br>
Philip<br>
<br>
<br>
I don't quite understand how the concrete Interpreter/MCJIT linking via<br>
> llvm/ExecutionEngine/Interpreter.h and llvm/ExecutionEngine/MCJIT.h works.<br>
> So far I was only using ExecutionEngine.h without Interpreter or MCJIT, so<br>
> that could have been the problem why static linking didn't work.<br>
><br>
> After playing around with Zhangs solution I've found out that I get the<br>
> same undefined symbol to llvm::EngineBuilder error when omitting the MCJIT<br>
> header and lib (since I actually only need an interpreter), my guess is<br>
> that this is due to Interpreter.h missing the getenv trick used in MCJIT.h<br>
> to prevent it being optimized away by the compiler? I might take a closer<br>
> look at this at some point, right now I'm just happy to finally be able to<br>
> work on my opt pass.<br>
><br>
><br>
> Thanks,<br>
><br>
> Viktor<br>
><br>
><br>
> On 4/18/19 7:38 PM, John Brawn wrote:<br>
><br>
> The fundamental problem here is that opt doesn’t use ExecutionEngine<br>
> (because it has no need to), so trying<br>
><br>
> to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for<br>
> that matter) in an opt plugin isn’t<br>
><br>
> going to work.<br>
><br>
><br>
><br>
> The solution I’d go with would be to build llvm with shared libraries (use<br>
> –DBUILD_SHARED_LIBS=ON on the<br>
><br>
> cmake command) then link the plugin against ExecutionEngine. That<br>
> shouldn’t require any changes anywhere<br>
><br>
> (when I gave it a quick try it seemed to work).<br>
><br>
><br>
><br>
> John<br>
><br>
><br>
><br>
> *From:* llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-bounces@lists.llvm.org</a><br>
> <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-bounces@lists.llvm.org</a>>] *On Behalf Of *Zhang via llvm-dev<br>
> *Sent:* 16 April 2019 22:04<br>
> *To:* Viktor Was BSc; llvm-dev<br>
> *Subject:* Re: [llvm-dev] Opt plugin linkage<br>
><br>
><br>
><br>
> Just another follow-up, seems like ExecutionEngine is still not usable<br>
> without editing CMakeLists, on my setup I had to edit CMakeLists.txt as<br>
> well to get the example working.<br>
><br>
> Below is the modifications I made:<br>
><br>
><br>
><br>
> Modified Hello.cpp for testing:<br>
><br>
> ```<br>
><br>
>     bool runOnFunction(Function &F) override {<br>
><br>
>       ++HelloCounter;<br>
><br>
>       std::string errStr;<br>
><br>
>       EngineBuilder eb;<br>
><br>
>       eb.setErrorStr(&errStr);<br>
><br>
>       eb.setEngineKind(EngineKind::Kind::JIT);<br>
><br>
>       ExecutionEngine* ee=eb.create();<br>
><br>
>       errs()<<"ExecutionEngine:"<<ee<<" Error:"<<errStr<<"\n";<br>
><br>
>       delete ee;<br>
><br>
>       errs() << "Hello: ";<br>
><br>
>       errs().write_escaped(F.getName()) << '\n';<br>
><br>
>       return false;<br>
><br>
>     }<br>
><br>
> ```<br>
><br>
><br>
><br>
> Modified opt's CMakeLists.txt:<br>
><br>
><br>
><br>
> ```<br>
><br>
> set(LLVM_LINK_COMPONENTS<br>
><br>
>   ${LLVM_TARGETS_TO_BUILD}<br>
><br>
>   AggressiveInstCombine<br>
><br>
>   Analysis<br>
><br>
>   BitWriter<br>
><br>
>   CodeGen<br>
><br>
>   Core<br>
><br>
>   MC<br>
><br>
>   MCJIT<br>
><br>
>   Object<br>
><br>
>   OrcJIT<br>
><br>
>   Interpreter<br>
><br>
>   RuntimeDyld<br>
><br>
>   Coroutines<br>
><br>
>   IPO<br>
><br>
>   IRReader<br>
><br>
>   InstCombine<br>
><br>
>   Instrumentation<br>
><br>
>   MC<br>
><br>
>   ObjCARCOpts<br>
><br>
>   ScalarOpts<br>
><br>
>   Support<br>
><br>
>   Target<br>
><br>
>   TransformUtils<br>
><br>
>   Vectorize<br>
><br>
>   Passes<br>
><br>
>   ExecutionEngine<br>
><br>
>   )<br>
><br>
><br>
><br>
> # Support plugins.<br>
><br>
> set(LLVM_NO_DEAD_STRIP 1)<br>
><br>
><br>
><br>
> add_llvm_tool(opt<br>
><br>
>   AnalysisWrappers.cpp<br>
><br>
>   BreakpointPrinter.cpp<br>
><br>
>   Debugify.cpp<br>
><br>
>   GraphPrinters.cpp<br>
><br>
>   NewPMDriver.cpp<br>
><br>
>   PassPrinters.cpp<br>
><br>
>   PrintSCC.cpp<br>
><br>
>   opt.cpp<br>
><br>
><br>
><br>
>   DEPENDS<br>
><br>
>   intrinsics_gen<br>
><br>
>   )<br>
><br>
> export_executable_symbols(opt)<br>
><br>
><br>
><br>
> if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)<br>
><br>
>   target_link_libraries(opt PRIVATE Polly)<br>
><br>
> endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)<br>
><br>
> target_link_libraries(opt PUBLIC LLVMExecutionEngine)<br>
><br>
><br>
><br>
> ```<br>
><br>
><br>
><br>
> Modified opt's LLVMBuild.txt:<br>
><br>
><br>
><br>
> ```<br>
><br>
> ;===- ./tools/opt/LLVMBuild.txt --------------------------------*- Conf<br>
> -*--===;<br>
><br>
> ;<br>
><br>
> ;                     The LLVM Compiler Infrastructure<br>
><br>
> ;<br>
><br>
> ; This file is distributed under the University of Illinois Open Source<br>
><br>
> ; License. See LICENSE.TXT for details.<br>
><br>
> ;<br>
><br>
><br>
> ;===------------------------------------------------------------------------===;<br>
><br>
> ;<br>
><br>
> ; This is an LLVMBuild description file for the components in this<br>
> subdirectory.<br>
><br>
> ;<br>
><br>
> ; For more information on the LLVMBuild system, please see:<br>
><br>
> ;<br>
><br>
> ;   <a href="http://llvm.org/docs/LLVMBuild.html" rel="noreferrer noreferrer" target="_blank">http://llvm.org/docs/LLVMBuild.html</a><br>
><br>
> ;<br>
><br>
><br>
> ;===------------------------------------------------------------------------===;<br>
><br>
><br>
><br>
> [component_0]<br>
><br>
> type = Tool<br>
><br>
> name = opt<br>
><br>
> parent = Tools<br>
><br>
> required_libraries =<br>
><br>
>  AsmParser<br>
><br>
>  BitReader<br>
><br>
>  BitWriter<br>
><br>
>  CodeGen<br>
><br>
>  IRReader<br>
><br>
>  IPO<br>
><br>
>  Instrumentation<br>
><br>
>  Scalar<br>
><br>
>  ObjCARC<br>
><br>
>  Passes<br>
><br>
>  ExecutionEngine<br>
><br>
>  Interpreter<br>
><br>
>  MCJIT<br>
><br>
>  Native<br>
><br>
>  NativeCodeGen<br>
><br>
>  all-targets<br>
><br>
><br>
><br>
> ```<br>
><br>
><br>
><br>
> On top of that I also added these lines to the beginning of main function<br>
> in opt.cpp to force linking ExecutionEngine:<br>
><br>
><br>
><br>
> ```<br>
><br>
>   if(argc==-1){<br>
><br>
>     EngineBuilder eb;<br>
><br>
>     ExecutionEngine* ee=eb.create();<br>
><br>
>     delete ee;<br>
><br>
>   }<br>
><br>
> ```<br>
><br>
><br>
><br>
> as well as force linking MCJIT and Interpreter by including headers in opt:<br>
><br>
><br>
><br>
> ```<br>
><br>
> #include "llvm/ExecutionEngine/ExecutionEngine.h"<br>
><br>
> #include "llvm/ExecutionEngine/Interpreter.h"<br>
><br>
> #include "llvm/ExecutionEngine/MCJIT.h"<br>
><br>
> ```<br>
><br>
><br>
><br>
> Moving cl::parseCommandLineOptions doesn't seem to be related to the<br>
> issue, my previous assumption was wrong.<br>
><br>
><br>
><br>
> Those modifications works at least on my setup with the following output:<br>
><br>
><br>
><br>
> ```<br>
><br>
> λ : >>> bin/opt -load lib/LLVMHello.dylib hw.ll -hello<br>
><br>
> WARNING: You're attempting to print out a bitcode file.<br>
><br>
> This is inadvisable as it may cause display problems. If<br>
><br>
> you REALLY want to taste LLVM bitcode first-hand, you<br>
><br>
> can force output with the `-f' option.<br>
><br>
><br>
><br>
> Assertion failed: (M && "Module is null?"), function Init, file<br>
> /Users/naville/Development/Hikari/lib/ExecutionEngine/ExecutionEngine.cpp,<br>
> line 80.<br>
><br>
><br>
><br>
> ```<br>
><br>
><br>
><br>
> Which is due to i didn't initialize the EEBuilder properly, but at least<br>
> the pass now loads and executes properly<br>
><br>
><br>
><br>
><br>
><br>
> Zhang<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> ------------------ Original ------------------<br>
><br>
> *From: * "Zhang via llvm-dev"<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>;<br>
><br>
> *Date: * Wed, Apr 17, 2019 04:35 AM<br>
><br>
> *To: * "Viktor Was BSc"<<a href="mailto:gs15m015@technikum-wien.at" target="_blank" rel="noreferrer">gs15m015@technikum-wien.at</a>><br>
> <<a href="mailto:gs15m015@technikum-wien.at" target="_blank" rel="noreferrer">gs15m015@technikum-wien.at</a>>; "llvm-dev"<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>;<br>
><br>
> *Subject: * Re: [llvm-dev] Opt plugin linkage<br>
><br>
><br>
><br>
> Hey:<br>
><br>
> I spent sometime debugging this, it seems like editing<br>
> ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv,<br>
><br>
>     "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the<br>
> beginning of main() solved it for me. I'm not sure if this is a bug on LLVM<br>
> side<br>
><br>
><br>
><br>
><br>
><br>
> Zhang<br>
><br>
><br>
><br>
><br>
><br>
> ------------------ Original ------------------<br>
><br>
> *From: * "Viktor Was BSc via llvm-dev"<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>;<br>
><br>
> *Date: * Wed, Apr 17, 2019 03:09 AM<br>
><br>
> *To: * "llvm-dev"<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>;<br>
><br>
> *Subject: * Re: [llvm-dev] Opt plugin linkage<br>
><br>
><br>
><br>
> How come the hello pass example is so totally useless as a starting point?<br>
> Why is this not using any library/compontent which could conflict with opt<br>
> or clang and showing how to handle this? I have no clue as to how I have to<br>
> setup llvm to get this to work or why it doesn't work in the first place<br>
> with the setup described in "Getting started" and "writing an llvm pass"<br>
> pages etc.<br>
><br>
> Also there is basically no documentation for the custom cmake commands.<br>
><br>
> Can please somebody help me with this issue? How do I get dynamically<br>
> loaded llvm pass plugins to work? Am I the only one ever having this issue?<br>
><br>
> Thanks<br>
><br>
> Viktor<br>
><br>
> On Apr 16, 2019, at 05:38, Viktor Was BSc via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I have a dynamically loaded llvm pass built in-tree with ninja (generated<br>
> with cmake, basically a copy of the hallo pass plugin, linux, llvm/clang<br>
> version 6.0.1).<br>
><br>
> It uses the ExecutionEngine.<br>
><br>
> Building it without linking against LLVMExecutionEngine library results in<br>
> an undefined symbol to the vtable of the EngineBuilder when loaded to opt.<br>
> Linking the plugin with LLVMExecutionEngine results in the pass simply not<br>
> being executable with giving "opt: Unkown command line argument<br>
> '-passArg'."<br>
><br>
> For a minimal example add set(LLVM_LINK_COMPONENTS Core) to the<br>
> CMakeLists.txt of the Hello llvm pass.<br>
><br>
> There is no error or warning at any point when linking or loading a plugin<br>
> linked against some  libs.<br>
><br>
> How do I find out which llvm libs I can't link with a dynamically loaded<br>
> plugin?<br>
><br>
> How can I use the EngineBuilder in my plugin with proper symbol resolution?<br>
><br>
> For reproductivity:<br>
><br>
> cmake -G "Sublime Text 2 - Ninja" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON<br>
> -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON -DLLVM_BUILD_TESTS=ON<br>
> -DLLVM_BUILD_EXAMPLES=ON -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra"<br>
> -DLLVM_TOOL_CLANG_BUILD=ON -DLLVM_TOOL_CLANG_TOOLS_EXTRA=ON<br>
> -DLLVM_OPTIMIZED_TABLEGEN=ON -DCLANG_BUILD_EXAMPLES=ON<br>
> -DCLANG_PLUGIN_SUPPORT=ON<br>
><br>
> Hope someone can help me out.<br>
><br>
> Viktor<br>
><br>
> ------------------------------<br>
><br>
><br>
> LLVM Developers mailing listllvm-dev@lists.llvm.orghttps://<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/617ee6a5/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/617ee6a5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 19 Apr 2019 07:43:25 -0500<br>
From: Brian Cain via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank" rel="noreferrer">tstellar@redhat.com</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>, Release-testers<br>
        <<a href="mailto:release-testers@lists.llvm.org" target="_blank" rel="noreferrer">release-testers@lists.llvm.org</a>>, cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>>,<br>
        "openmp-dev \(<a href="mailto:openmp-dev@lists.llvm.org" target="_blank" rel="noreferrer">openmp-dev@lists.llvm.org</a>\)"<br>
        <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank" rel="noreferrer">openmp-dev@lists.llvm.org</a>>, LLDB Dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" rel="noreferrer">lldb-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] [Release-testers] LLVM 7.1.0-final has been<br>
        tagged<br>
Message-ID:<br>
        <<a href="mailto:CAEWpfG8%2B42peP9S%2BxdT%2BxYJ3kULFqHYVka4gfjKMws5thrG9zg@mail.gmail.com" target="_blank" rel="noreferrer">CAEWpfG8+42peP9S+xdT+xYJ3kULFqHYVka4gfjKMws5thrG9zg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Uploaded Ubuntu 14 and SLES 11 x86 binaries.<br>
<br>
8a5d880f3ed2b10d80660d1029b0c958878c3cb7<br>
clang+llvm-7.1.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz<br>
81f5b08cc8cac534e4a7405de46a2ef28d978477<br>
clang+llvm-7.1.0-x86_64-linux-sles11.3.tar.xz<br>
<br>
<br>
On Thu, Apr 11, 2019 at 7:00 PM Tom Stellard via Release-testers <<br>
<a href="mailto:release-testers@lists.llvm.org" target="_blank" rel="noreferrer">release-testers@lists.llvm.org</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I've just tagged LLVM 7.1.0-final.  Testers, please upload the final<br>
> binaries.<br>
><br>
> Thanks,<br>
> Tom<br>
> _______________________________________________<br>
> Release-testers mailing list<br>
> <a href="mailto:Release-testers@lists.llvm.org" target="_blank" rel="noreferrer">Release-testers@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers</a><br>
><br>
<br>
<br>
-- <br>
-Brian<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/fb2befb2/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/fb2befb2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 18 Apr 2019 12:58:42 -0700<br>
From: Neil Ryan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: "=?utf-8?Q?llvm-dev=<a href="http://40lists.llvm.org?=" rel="noreferrer noreferrer" target="_blank">40lists.llvm.org?=</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>,<br>
        "=?utf-8?Q?tstellar=<a href="http://40redhat.com?=" rel="noreferrer noreferrer" target="_blank">40redhat.com?=</a>" <<a href="mailto:tstellar@redhat.com" target="_blank" rel="noreferrer">tstellar@redhat.com</a>>,  Arsenault,<br>
        Matthew <<a href="mailto:Matthew.Arsenault@amd.com" target="_blank" rel="noreferrer">Matthew.Arsenault@amd.com</a>><br>
Subject: Re: [llvm-dev] Disable combining of loads and stores in<br>
        instcombine<br>
Message-ID: <b56ad594-d89e-4f65-900c-47834f2d5cf1@Spark><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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.<br>
<br>
Neil<br>
On Apr 17, 2019, 12:31 PM -0700, Arsenault, Matthew <<a href="mailto:Matthew.Arsenault@amd.com" target="_blank" rel="noreferrer">Matthew.Arsenault@amd.com</a>>, wrote:<br>
> 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.<br>
><br>
> -Matt<br>
><br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-bounces@lists.llvm.org</a>> on behalf of llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
> Reply-To: Neil Ryan <<a href="mailto:neilryan@cs.washington.edu" target="_blank" rel="noreferrer">neilryan@cs.washington.edu</a>><br>
> Date: Wednesday, April 17, 2019 at 9:28 PM<br>
> To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>, "<a href="mailto:tstellar@redhat.com" target="_blank" rel="noreferrer">tstellar@redhat.com</a>" <<a href="mailto:tstellar@redhat.com" target="_blank" rel="noreferrer">tstellar@redhat.com</a>><br>
> Subject: Re: [llvm-dev] Disable combining of loads and stores in instcombine<br>
><br>
> 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.<br>
> On Apr 16, 2019, 8:17 PM -0700, Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank" rel="noreferrer">tstellar@redhat.com</a>>, wrote:<br>
><br>
> > On 04/16/2019 11:38 AM, Neil Ryan via llvm-dev wrote:<br>
> ><br>
> > > 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 <<a href="http://llvm.1065342.n5.nabble.com/disabling-combining-load-stores-in-optimizer-td37560.html" rel="noreferrer noreferrer" target="_blank">http://llvm.1065342.n5.nabble.com/disabling-combining-load-stores-in-optimizer-td37560.html</a>> from 2009 -- it seems like it wasn't possible then. Has anything changed since?<br>
> ><br>
> > Why do you want to disable this optimization?<br>
> ><br>
> > -Tom<br>
> ><br>
> ><br>
> ><br>
> > > Neil<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > LLVM Developers mailing list<br>
> > > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
> > > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> ><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20190418/440559e2/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/attachments/20190418/440559e2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 19 Apr 2019 11:13:26 -0700<br>
From: Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank" rel="noreferrer">maskray@google.com</a>><br>
Cc: LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>>, James<br>
        Henderson <<a href="mailto:jh7370@my.bristol.ac.uk" target="_blank" rel="noreferrer">jh7370@my.bristol.ac.uk</a>><br>
Subject: Re: [llvm-dev] Accept --long-option but not -long-option for<br>
        llvm binary utilities<br>
Message-ID:<br>
        <CACs=ty+EcWbrcpNep_g_RMxfLEyPymSjR65+qV3WnrZX380=<a href="mailto:2w@mail.gmail.com" target="_blank" rel="noreferrer">2w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Are you proposing to make this the new style across all LLVM utilities?<br>
That seems needlessly disruptive. There are plenty of scripts that call<br>
`opt` and `llc` directly with single dash long options, regardless of how<br>
much we claim that they are not public facing, and are only developer tools.<br>
<br>
If you want to add a flag to ParseCommandLineOptions so that individual<br>
LLVM tools can opt into the new behavior gradually, I think that would be<br>
reasonable.<br>
<br>
On Mon, Apr 15, 2019 at 11:41 PM Fāng-ruì Sòng via llvm-dev <<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
<br>
> Many llvm utilities use cl::ParseCommandLineOptions()<br>
> (include/Support/CommandLine.h) to parse command line options. The cl<br>
> library accepts both -long-option and --long-option forms, with the single<br>
> dash form (-long-option) being more popular.<br>
><br>
> We also have many binary utilities (llvm-objcopy llvm-objdump llvm-readobj<br>
> llvm-size ...) whose names reflect what they imitate. For compatibility<br>
> with GNU binutils (and some Unix utilities transitively), these utilities<br>
> accept many short options. People who use llvm utilities as replacement of<br>
> GNU binutils may use the grouped option syntax (POSIX Utility Conventions),<br>
> e.g. -Sx => -S -x, -Wd => -W -d, -sj.text => -s -j.text<br>
><br>
> The problem is, grouped short options don't play well with -long-option.<br>
> Sometimes there can be ambiguity. The issue is more prominent if the short<br>
> option accepts an argument.<br>
><br>
> An approach to prevent the ambiguity is to just disallow -long-option.<br>
> In D60439, I plan to make llvm-objcopy accept --long-option but not<br>
> -long-option.<br>
> It will make its command line option parsing behave more like GNU objcopy<br>
> and less like a regular llvm utility. What do people think of the<br>
> divergence?<br>
><br>
> Further, can we make similar changes to other llvm binary utilities (their<br>
> names give people the expectation), especially those with many short<br>
> options such as llvm-objdump and llvm-readobj? llvm-readobj behaves like<br>
> GNU readelf if you name it "llvm-readelf". (I don't suggest disallowing<br>
> -long-option for utilities other than binutils)<br>
><br>
> (Note, llvm-objcopy is a new member of the family and it uses tablegen<br>
> based include/llvm/Option/Opton.h, instead of cl:: as other utilities do.)<br>
><br>
><br>
><br>
> --<br>
> 宋方睿<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/67914ec2/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/67914ec2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 19 Apr 2019 11:16:25 -0700<br>
From: Tanya Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
Subject: [llvm-dev] Mentors and projects needed for Season of Docs<br>
Message-ID: <<a href="mailto:E8AF8175-56D3-4690-A811-972604AA9665@llvm.org" target="_blank" rel="noreferrer">E8AF8175-56D3-4690-A811-972604AA9665@llvm.org</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
LLVM Developers,<br>
<br>
Google has a new program called Season of Docs <<a href="https://developers.google.com/season-of-docs/" rel="noreferrer noreferrer" target="_blank">https://developers.google.com/season-of-docs/</a>>. 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. <br>
<br>
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.<br>
<br>
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:<br>
<a href="https://developers.google.com/season-of-docs/docs/project-ideas" rel="noreferrer noreferrer" target="_blank">https://developers.google.com/season-of-docs/docs/project-ideas</a> <<a href="https://developers.google.com/season-of-docs/docs/project-ideas" rel="noreferrer noreferrer" target="_blank">https://developers.google.com/season-of-docs/docs/project-ideas</a>><br>
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.<br>
<br>
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).<br>
<br>
If you have questions, please let me know. As this program is new, we are all trying to figure it out :)<br>
<br>
Thank you,<br>
Tanya Lattner<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/5c77b929/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/5c77b929/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
llvm-dev mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of llvm-dev Digest, Vol 178, Issue 56<br>
*****************************************<br>
</blockquote></div>