similar to: [LLVM LTO]internalize pass

On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program in gcc) in clang and in the below case > > define i32 @test() #0 { > > entry: > > ret i32 0 >

> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program

> On May 27, 2016, at 9:57 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi All ,

> On 2016-May-27, at 10:47, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On May 27, 2016, at 9:57 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>> >>> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> >>>

Hi Hal, Thanks for your hint! $ /opt/llvm-svn/bin/opt -S -internalize -internalize-public-api-list=main -globaldce hello3.ll -o hello3.dce.ll    it works :) But I argue that `main` Function should be inserted into ExternalNames by default: Index: lib/Transforms/IPO/Internalize.cpp =================================================================== --- lib/Transforms/IPO/Internalize.cpp 

Hi LLVM developers, $ cat hello.c #include <stdio.h> void foo() { } int main(int argc, char *argv[]) {   for (int i = 0; i < 10; i++) {     printf("%d\n", i);   }   return 0; } $ /opt/llvm-svn/bin/clang --version Fedora clang version 6.0.0 (trunk 316308) (based on LLVM 6.0.0svn) Target: x86_64-redhat-linux Thread model: posix InstalledDir: /opt/llvm-svn/bin $

Hi There , Again ,I'm newbie to LLVM and please pardon me ..if you guys feel that ,the below question is very basic :) Here i go ,compiled the below sample with clang i.e *clang enum.c -S -emit-llvm* and there respective file are $ cat enum.c int main() { enum type{one=1,two,three} s; s = one; return s; } $ cat enum.s ; ModuleID = 'enum.c' target datalayout =

On Thu, Feb 2, 2012 at 12:25 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi There , > > Again ,I'm newbie to LLVM  and please pardon me ..if you guys  feel that > ,the below question is very basic :) > > Here i go ,compiled the below sample with clang i.e clang enum.c -S > -emit-llvm and there respective file are > > $ cat enum.c > int main()

On 7 June 2016 at 10:54, Shi, Steven <steven.shi at intel.com> wrote: > Hi Rafael, > I finally enable the clang LTO build with small code model and PIE, and my clang LTO Uefi firmware works now. Thank you! But I have one more issue on the clang normal build (without LTO) now. I find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL

On 31 May 2016 at 01:08, Shi, Steven <steven.shi at intel.com> wrote: > Hi Mehdi, > What's the default code model for x86_64 Mac OS X App? Andrew showed me some example code of Mac OS X App as below, which looks to use the small code model but can run at >4GB high address. Small, but PIC. > For example if you read a global like this the compiler will generate this code.

> On May 29, 2016, at 5:10 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I don't know anything about GCC. (And I doubt the GNU linker supports LTO with LLVM). > I’m a

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > > Steven, > > As mehdi stated , the optimisation level is specific to linker and it > enables Inter-Pro opts passes ,please refer function To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO. -- Mehdi > >

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at

> On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070 <https://sourceware.org/bugzilla/show_bug.cgi?id=20070>. The new GNU ld linker works well with

Hi, > On May 29, 2016, at 7:36 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if

Hi Mehdi, After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if you could let me know it. You know, parts of my Uefi firmware (BIOS) have to been loaded to run in high

(And I doubt the GNU linker supports LTO with LLVM). [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070. The new GNU ld linker works well with LLVM/Clang LTO when build IA32 code in my side. And from the ld owner input in the bug comments, the current X64 LLVM LTO issue is in llvm LTO plugin. The fact

Hi Steven, > On May 29, 2016, at 11:28 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? I wrote it on trunk, but I expect it to be fairly easy to port on 3.8. This is really just quickly plumbing an option on the TargetMachine creation. --

Hi Guys , We enabled the LTO on our code base and found that LTO uses the integrated/builtin assembler to emit the final optimized code .O (FileType= CGFT_ObjectFile) . Can we bypass this semantic ,for something like you emit .S file (FileType=CGFT_AssemblyFile), Then we pass this .S file to our native assembler and the linker .....any switch/ options do so ? i.e something like as we have

Hi Mehdi, GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I'm a bit surprised if both OS X ld64 and gold plugin do not support large code model in LTO. Since modern system widely use the 64bit, the code need to run in high address (larger than 2 GB) is a