similar to: [RFC] lld: Dropping TLS relaxations in favor of TLSDESC

On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS > access > > models, so I think we can drop TLS relaxation support from lld. > > > > lld's code to handle

On Tue, Nov 7, 2017 at 8:16 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> So I am strongly against removing either non TLSDESC support of support > >> for the relaxations. > >> > > > > It's still pretty arguable. By default, compilers use General Dynamic > model

On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> If you are creating an executable and if your executable is not > >> > position-independent, you're using Initial Exec model by default > which is > >> > as fast as variables accessed through

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

On 2 June 2016 at 20:49, Rafael Espindola via llvm-commits <llvm-commits at lists.llvm.org> wrote: > Author: rafael > Date: Thu Jun 2 14:49:53 2016 > New Revision: 271569 > > URL: http://llvm.org/viewvc/llvm-project?rev=271569&view=rev > Log: > Start adding tlsdesc support for aarch64. > > This is mostly extracted from http://reviews.llvm.org/D18960. Rafael,

On 3 June 2016 at 18:47, Rui Ueyama <ruiu at google.com> wrote: > Renato, it is not appropriate to call it my and Rafael's pet project. Hi Rui, I apologise, that was wrong in all levels. I know how much other people have contributed, but these people are on the inside already, so their contributions are more easily accepted. We have been trying to contribute for more than a year

On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Because the patch includes way too much and doesn't explain what it is doing. So let me get this straight: someone publishes a patch, you don't like it, you do some private investigations and commit whatever you want without even notifying the original authors? I don't know how you work at

By the way, since this is an optional code relaxation, we can think about it later. The first thing I would do is to add RISC-V support to lld without code shrinking relaxations, which I believe is doable by at most a few hundreds lines of code. On Wed, Jul 12, 2017 at 3:21 AM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jul 11, 2017 at 9:14 PM, Bruce Hoult via llvm-dev < >

Here's an example using the gcc toolchain for embedded 32 bit RISC-V (my HiFive1 board): #include <stdio.h> int foo(int i){ if (i < 100){ printf("%d\n", i); } return i; } int main(){ foo(10); return 0; } After compiling to a .o with -O2 -march=RV32IC we get (just looking at foo) 00000000 <foo>: 0: 1141 addi sp,sp,-16

On 3 June 2016 at 01:53, Rui Ueyama <ruiu at google.com> wrote: > Not so fast to conclude that the community is not trustworthy, it doesn't > consist of a single person or a single action. This is not an isolated incident. This seems to be the general behaviour around LLD, which is less so in the rest of the LLVM projects. The obliteration of the old ELF back-end was discussed

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

Hi, Some time ago there were some information about aarch64 support for the lld linker project: http://lld.llvm.org/open_projects.html#elf-aarch64 Right now there is no such information. Also there is some presentation described that the simple application can be linked using lld: http://llvm.org/devmtg/2016-03/Presentations/EuroLLVM%202016-%20New%20LLD%20linker%20for%20ELF.pdf What is the

Hi, I've encountered a newly introduced bug in lld today. I am building my program with clang and lld on an X86-64 Ubuntu Linux machine. Command line: clang main.c The compiled program invokes the "main" function multiple times until it closes with a segmentation fault. This affects even the most primitive programs like "int main() { return 0; }". The problem

Hi folks, I'd like to propose adding a feature to ELF lld for automatically partitioning a program into multiple binaries. (This will also involve adding a feature to clang, so I've cc'd cfe-dev as well.) == Problem statement == Embedded devices such as cell phones, especially lower end devices, are typically highly resource constrained. Users of cell phone applications must pay a

Hi, On Wed, Jul 12, 2017 at 2:21 AM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks, Bruce. This is a very interesting optimization. > > lld doesn't currently have code to support that kind of code shrinking > optimization, but we can definitely add it. It seems that essentially we > need to iterate over all relocations while rewriting

On 3 June 2016 at 17:10, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Do keep in mind you are comparing a 11 year old project and a 11 month > old one. There is a lot more churn on the 11 month old one. LLD is at least 5 years old. Every time you re-write it doesn't reset history. > Again, I am truly sorry we were unable to come up with a perfect > design the

We have fairly large and complex code to handle relocations in Writer.cpp, Target.cpp, OutputSections.cpp and InputSections.cpp. They started with simple code, but because each patch added a small piece of code to the existing one, it is becoming out of control now. For example, we have lots of entangled boolean flags in the functions that interfere with each other in an obscure fashion. Even I

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom

Hi, I've tagged the LLVM 9.0.1-rc1 release. Testers can begin testing and upload binaries. I've also updated the test-release.sh script to pull from GitHub instead of SVN, if you run into any issues with the new script, let me know. -Tom

Greetings, We, at Google, recently evaluated Facebook’s BOLT, a Post Link Optimizer framework, on large google benchmarks and noticed that it improves key performance metrics of these benchmarks by 2% to 6%, which is pretty impressive as this is over and above a baseline binaryalready heavily optimized with ThinLTO + PGO. Furthermore, BOLT is also able to improve the performance of binaries