similar to: Refactor BitcodeWriter into classes?

> On 2016-Apr-21, at 11:41, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Apr 21, 2016, at 11:25 AM, Teresa Johnson <tejohnson at google.com> wrote: >> >> I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long

I have a question about module-level METADATA_BLOCKs in the bitcode. There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function

Hey all, For LinkModules, /*dest*/ is a fully materialized module, /*src*/ is a lazily loaded module. From what I understood, getLinkedToGlobal() is finding the function in /*src*/ that matches some function declaration in /*dest*/, and given that /*src*/ is lazily loaded it could be un-materialized. The functions I need brought in from /*src*//**/ into /*dest*/ are always declarations in

On Wed, Apr 29, 2015 at 11:19 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 10:55 AM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> On Wed, Apr 29, 2015 at 10:05 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> > >> > >> > On Wed, Apr 29, 2015 at 9:48 AM, Teresa Johnson

On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Small repro: > > __attribute__((weak)) int hello_world(); > > int test() { > if (hello_world) > return hello_world(); > return 0; > } > > $ clang -fuse-ld=gold -flto=thin -O2 -shared -fPIC -o libmore.so more.c > $ objdump -t libmore.so |grep hello >

GCC LTO works ok for the test case with both bfd and gold linker. David On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote:

No problem! I want to make sure you aren't blocked on trying ThinLTO. Thanks, Teresa On Mon, Aug 15, 2016 at 2:50 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Sorry I was working on another LLVM issue that more urgent for us, so > didn’t have much time to work on smaller test case. I’ll try the new API > and see if the issus is gone. Thanks! >

I just built a stage-1 compiler from the 3.9 release bits and built the lldb from head sources which worked fine. Let me try again using 3.9 build compiler to build 3.9 bits. Teresa On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com> > wrote: > >> On

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

On Wed, Apr 29, 2015 at 10:05 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 9:48 AM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> Ok, thanks for the suggestion. I will rework the tests to do that. > > > In case you haven't found it already, %T in the lit syntax gives you a > uniquely named directory for

LLD revision is r331862. To add, I had initially tried it on r328903, which also reproduced the issue. On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > Hi Teresa, > > Thanks for looking into this. I hadn't initially tried ToT, but it > reproduces in ToT as well when I tried. > > $ ./clang --version > > clang version 7.0.0

Yes running LLVM performance test suite with LTO and Thin LTO enabled. Thanks, Siddharth On Fri, May 11, 2018 at 7:32 PM, Teresa Johnson <tejohnson at google.com> wrote: > I'm not completely sure what you are asking. Are you looking for > performance benchmarks to use for LTO and ThinLTO testing? Or are you > asking how to build/run with LTO and ThinLTO? Are you asking how to

I still wonder if this would be an issue in _standard_ (not thin) LTO? This test seems to be OK on my (slightly modified) standard LTO flow, but I do wonder for a more general case. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Collingbourne

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,

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

Hi Taewook, I had a better fix for this approved (D23015), but when I went to merge this with the new LTO API I committed for pcc last week I discovered that his new API already has the same effect. I will update the bug with this info as well. Can you confirm that with a compiler built after 278338 that this problem no longer occurs? Also, any luck on a smaller test case for the -g issue? Now

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

Thanks Easwaran. This is what we've observed as well, where the old PM inliner was only looking hot/cold callee information, which have signficantly smaller boosts/penalties compared to callsite information. Teresa, do you know if there is some documentation/video/presentation on how PGO information is represented in LLVM and what information is passed via the IR? I'm finding some

Ok, thanks for the suggestion. I will rework the tests to do that. Teresa On Wed, Apr 29, 2015 at 9:47 AM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed, Apr 29, 2015 at 9:36 AM Justin Bogner <mail at justinbogner.com> wrote: >> >> Teresa Johnson <tejohnson at google.com> writes: >> > On Wed, Apr 29, 2015 at 6:27 AM, Renato Golin

The direct cause of this issue is that, previously lld converted common symbols to defined symbols before passing input files to LTO, and after r360841 they are passed as common symbols to LTO. Making lld to work as before is easy, as we can convert common symbols to defined symbols as before. Here is a patch to do that, and I confirmed that that restores the original behavior for the reported