similar to: Target Specific LTO Machine Pass

Here in an example that explains the difference. // Only declaration – No implementation // Assume that the value is returned in EAX and the arguments are passed in EAX, ECX, EDX, ESI, EDI. int __regcall callee (int a, int b, int c, int d, int e); // implemented in a different module void caller() { … x = callee(1,2,3,4,5); … } What will be RegMask using IPRA register usage collector? Callee

Hi Mehdi, I think that the subject of the RFC is misleading. The true problem that we are trying to solve is to remove returned/passed arguments from the regmask (According to the calling convention). IPRA and CC updated RegMask can’t use the same mechanism because they contradict each other. I think that the following analog will help to explain why I think that a reuse is redundant: Let’s

Hi Mehdi, It is true that both IPRA and the proposed mechanism save RegMasks. So you might say that the data structure in the immutable pass should be reused, but this is the only similarity. Even this similarity is not exactly true. I save register masks that doesn’t use passed/returned arguments while IPRA saves register masks for modified registers. So how can they share the same mechanism?

Hi Mehdi, I wasn’t familiar with IPRA before, thank you for bringing it up. After studying it, I have to say that IPRA is a wonderful idea and is well implemented. I tried to reuse the mechanism for the last couple of days. I implemented a solution using IPRA mechanism and encountered few issues: 1. IPRA uses immutable analysis pass called “PhysicalRegisterUsageInfo”. The usage of such

Hi All, The Register Calling Convention (RegCall) was introduced by Intel to optimize parameter transfer on function call. This calling convention ensures that as many values as possible are passed or returned in registers. To use RegCall, place the keyword before a function declaration. For example: __regcall int foo (int i, int j); // Windows OS __attribute__((regcall)) foo (int I, int j); //

yeah so when LTO runs, in the linker, it uses the target to produce object code. In the sense of code generation for target arch. Thanks, Siddharth On Mon, Jan 29, 2018 at 11:03 PM, Teresa Johnson <tejohnson at google.com> wrote: > Can you be more specific? LTO/ThinLTO are target independent. You just > need to be using a linker that supports *LTO (gold, lld, ld64, eg). > Teresa

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

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

Dynamically Allocated "Callee Saved Registers" Lists Each Calling convention (CC) defines a static list of registers that should be preserved by a callee function. All other registers should be saved by the caller. Some CCs use additional condition: If the register is used for passing/returning arguments - the caller needs to save it - even if it is part of the Callee Saved Registers

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

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,

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 >

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 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

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:

Hopefully someone else on the dev list who has experience with LNT and the LLVM test-suite will chime in. I've never run it myself. Adding Mehdi since he ran it with LTO/ThinLTO. I found some documentation for the test-suite: https://llvm.org/docs/TestingGuide.html#test-suite-overview http://llvm.org/docs/lnt/quickstart.html http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite But I

Hi, Thanks for the info, If i only want to run performance test on benchmarks for LTO and Thin LTO enabled target, Can u suggest ways to do it ? I want to do it at my end. Thanks, Siddharth On Wed, May 2, 2018 at 7:03 PM, Teresa Johnson <tejohnson at google.com> wrote: > I've only measured performance on x86. There are some old results for SPEC > cpu2006 in the blog post here:

No worries, thanks for the update. Teresa On Mon, Sep 26, 2016, 7:16 AM Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 3:52 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > ThinLTO needs to create as many temporary files as there are input > > modules to the link. From your 'ls' below, it doesn't look

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

On Wed, Apr 6, 2016 at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, Apr 6, 2016 at 10:49 AM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Wed, Apr 6, 2016 at 10:46 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> I suspect that the right way to do promotion/renaming of this