similar to: PIC and mcmodel=large on x86 doesn't use any relocations

> > Message: 2 > Date: Sat, 29 Oct 2016 22:36:41 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161029203641.GB20270 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii >

> Message: 4 > Date: Thu, 27 Oct 2016 22:04:28 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161027200428.GA2177 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii > > On

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

On 05/30/16 01:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > We don't use cl::opt in gold, instead we parse the -plugin-opts that > gold passes the plugin (see process_plugin_option). > What about that: $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp // ParseCommandLineOptions () expects argv[0] to be program name. Lazily cl::

> > Message: 3 > Date: Thu, 27 Oct 2016 17:12:53 -0400 > From: John Reagan via llvm-dev <llvm-dev at lists.llvm.org> > To: <llvm-dev at lists.llvm.org>, <llvm-dev-request at lists.llvm.org> > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <00cf01d23096$e1e14430$a5a3cc90$@net> > Content-Type:

We don't use cl::opt in gold, instead we parse the -plugin-opts that gold passes the plugin (see process_plugin_option). Cheers, Rafael On 30 May 2016 at 02:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > > 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

(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

> 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

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

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

Hi All It''s been just over two weeks since LSRC 6 tickets went on sale, and it is already over half full. And now, it''s just 16 days to go for LSRC 6. That''s right, two weeks and two days from now you can see Laurent Sansonetti of RubyMotion fame, Uncle Bob Martin, and, best of all, Matz! The Lone Star Ruby Conference is being held Aug 9-11 in Austin, TX, at Norris

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

FILE_MEMORY_GLOBAL is currently only used for buffer handling, as we do not yet have (opencl) global memory support. Global memory support actually requires some different handling during lowering, so rename FILE_MEMORY_GLOBAL to FILE_MEMORY_BUFFER to reflect that the current code is for buffer handling, this will allow the later (re-)addition of FILE_MEMORY_GLOBAL for regular global memory.

Add support for OpenCL global memory buffers, note this has only been tested with regular load and stores and likely needs more work for e.g. atomic ops. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 31 +++++++++++++++++-----

Hi, On 16-03-16 15:55, Ilia Mirkin wrote: > This approach leads to the emitters needing to know about both global and > buffer, even though at that point, they are identical. I was thinking that > in the lowering logic, buffer would just get rewritten as global (with the > offset added), thus not needing any change to the emitters. What do you > think about such an approach? I was

> 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 16-03-16 11:37, Samuel Pitoiset wrote: > Could you please get rid of the cosmetic changes (eg. the switch ones)? > Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. I need at least halve of those cosmetic changes, because half of them is not cosmetic, e.g. : - case FILE_MEMORY_BUFFER: code[1] =

Hi Mehdi, The llvm3.8 gold-plugin.cpp is very different from the latest one on trunk. Your patch has compiling failure on llvm3.8 as below. I will try it on latest trunk later. Thank you help anyway! Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o cd /home/jshi19/llvm38releasebuild/tools/gold && /home/jshi19/clang38/bin/clang++ -DGTEST_HAS_RTTI=0

This approach leads to the emitters needing to know about both global and buffer, even though at that point, they are identical. I was thinking that in the lowering logic, buffer would just get rewritten as global (with the offset added), thus not needing any change to the emitters. What do you think about such an approach? On Mar 16, 2016 2:24 AM, "Hans de Goede" <hdegoede at

Change the assembly code to use the new _ASM_MOVABS macro which get a symbol reference while being PIE compatible. Adapt the relocation tool to ignore 32-bit Xen code. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/tools/relocs.c | 16