similar to: ThinLTO: module-scope inline assembly blocks

With `save-temps` as plugin option, I get extra files for the MAIN module (called `a.o`): `a.o.opt.bc` and `a.thinlto.bc`. The `a.thinlto.bc` file contains nothing, only `source_filename = ...` . The `a.o.opt.bc` (this looks like the result after ThinLTO importing and optimization) contains the assembly block that it should not have: ``` module asm "\09.text" module asm

The plugin version (and LLVM) are LLVM 3.9.0 (the release source tarball). I've attached the source files and the temporary files generated. `a.o` is the "MAIN" module. `b.o` is the "ASM" module. The error I get is: /usr/bin/ld: error: a.o.thinlto.o: multiple definition of 'foo' /usr/bin/ld: b.o.thinlto.o: previous definition here (the files depend on D runtime

On Mon, Oct 3, 2016 at 4:27 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:53 AM, Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> I am trying to add ThinLTO to the LDC compiler. It seems to work well >> on Mac (XCode 8) and Ubuntu (ld.gold + LLVMgold plugin). >> However, I am

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We

Hi all, I have a static library with object files with the same name (not the same full path, but the archive made with llvm-ar does not store the full path). The library contains object files that have been compiled with `-flto=thin` (compiled with LDC, not clang, but that shouldn't matter). When linking to that static library, I get the error: Assertion failed:

bfd linker 2.26 works fine with LLVMgold.so. As I mentioned in a previous email, 2.26 ar and ranlib also works fine as long as LLVMgold.so is put in a path binutils know about : $(bindir)/../lib/bfd-plugins/ David On Sun, Oct 2, 2016 at 3:59 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Sun, Oct 2, 2016 at 6:52 AM, Teresa Johnson <tejohnson at google.com> >

On Wed, Sep 6, 2017 at 1:10 PM, Johan Engelen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Sep 5, 2017 at 11:34 PM, Davide Italiano <dccitaliano at gmail.com> > wrote: >> >> On Tue, Sep 5, 2017 at 2:09 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> > >> > Hi Johan, >> > >> > Right, per the bug

On Mon, Oct 3, 2016 at 10:54 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Aha - finally reproduced! The difference is using ld.bfd not > ld.gold. With that I get the same failure (using 3.9 to build 3.9 > sources): Thanks a lot! [...] > I am not sure what the official support story is for LLVMgold.so and > ld.bfd. As mentioned earlier, the LLVM site indicates

Hi everybody. I'm having (yet) another look at trying to get naked functions from D (1) working in our LLVM D Compiler - LDC (2). I have this test case: /// D CODE /// extern(C) int printf(char*, ...); ulong retval() { asm { naked; mov EAX, 0xff; mov EDX, 0xaa; ret; } } ulong retval2() { return (cast(ulong)0xaa << 32) | 0xff; } void main() {

Is -fsplit-stack option used anywhere? My wild guess is that with ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from libgcc.a, but the hidden symbol is defined in lldb binary. David On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Aha - finally reproduced! The difference is using ld.bfd not ld.gold. With > that I

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson <tejohnson at google.com> wrote: > > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > > I use trunk, but it depends on how close to the bleeding edge you > > > are

On Fri, Sep 16, 2016 at 10:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Can you look for the specific errors in the CMake log and error files? > > CMake is very good at not presenting the real issue… > Here it is trying to build very simple programs to check features > availability. Like: > > #include <strings.h> > int main() { ffs(0); return 0;

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

In uint64_t RTDyldMemoryManager::getSymbolAddressInProcess(const std::string &Name) { there is reference to morestack: #if defined(__i386__) || defined(__x86_64__) // __morestack lives in libgcc, a static library. if (&__morestack && Name == "__morestack") return (uint64_t)&__morestack; #endif #endif // __linux__ && __GLIBC__ On Mon, Oct 3,

Oh I just see that there were already a bunch of answers. I missed the thread, sorry. So basically my intuitive approach on this is close to what I perceive Peter's position is: - don't create a new format if there is already one. - if you really have a good reason to create a new format, it should replace the existing one (i.e. don't maintain two). - ideally we should be able to

On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Why do we need a custom dumping format for the summary? Since we already > need the YAML format anyway, wouldn't it be better to extend that to cover > the entire summary? > IMO it is useful/convenient to be able to see the summary in the llvm-dis output. Teresa >

On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > What is the linker command line buidling liblldb.so? is libgcc.a passed in? > There is no difference in the linker command for liblldb.so or bin/lldb between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can see. The difference appears to be that the __morestack symbol is weak in

Hi, I am trying to test ThinLTO mode with lld, but am seeing failures because (at optimisation levels above -O0), clang inserts calls to clang.arc.use, which are expected to be removed by the ObjCARCCompact pass. Unfortunately, this pass doesn’t seem to be being run by lld (and adding -mllvm -print-after-all indicates that only SimplifyCFG is being run, which is a bit surprising, though the

On Sat, Jun 3, 2017 at 8:33 AM Teresa Johnson <tejohnson at google.com> wrote: > On Fri, Jun 2, 2017 at 8:41 PM, Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Oh I just see that there were already a bunch of answers. I missed the >> thread, sorry. >> >> So basically my intuitive approach on this is close to what I perceive