similar to: [LLVMdev] problems with TARGET_IASM_OP_CONSTRAINT

Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc branch. With this patch I am able to bootstrap the 4.0 branch using the new eabi. The llvm-gcc branch fails with ------------------------------------ internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14372 ------------------------------------ But I believe that this is an unrelated problem and I will

Newly-added undefined symbols may be solved by other file in the same archive, so you've got to restart scanning from beginning. You would visit the same symbol many times. Is that faster? On Fri, Mar 20, 2015 at 3:03 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I think that wouldn't work. When we find a member file in an archive > that > >

For example something like STARTUP ( http://wiki.osdev.org/Linker_Scripts#STARTUP) is not accepted by the LLVM LLD. :-/ On Wed, Apr 20, 2016 at 9:08 PM, Sky Flyer <skylake007 at gmail.com> wrote: > Yeah I found it, that's nice. Thanks a milion. > Could you please tell me how can I specify my bootstrap (startup code) in > the linking process? > > > On Wed, Apr 20, 2016

On 29 June 2016 at 02:49, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 29, 2016 at 12:17 PM Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: >> > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola >> > <rafael.espindola at

search for VAStart. Cheers, Rafael On 20 April 2016 at 14:18, Sky Flyer <skylake007 at gmail.com> wrote: > Hi Rafael, > > Thanks a lot. > For example the start entry for me is 0x11000 by default which I don't know > where it come from! I thought there should be a default thing that sets this > entry address. > > On Wed, Apr 20, 2016 at 8:05 PM, Rafael Espíndola

Sent from my iPhone > On May 30, 2016, at 4:52 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> On 30 May 2016 at 16:56, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> 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

On Wed, Jun 29, 2016 at 12:17 PM Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: > > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola > > <rafael.espindola at gmail.com> wrote: > >> > >> On 22 June 2016 at 16:36, Dean Michael Berris via llvm-dev > >>

On 28 June 2016 at 22:14, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 29, 2016 at 12:06 PM Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> On 22 June 2016 at 16:36, Dean Michael Berris via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > Peter suggested just writing out '.byte 0xeb, 0x09' and that

I think that's incorrect. It should to: .section .foo .L1: .L2 = .L1 .section .bar .long .L3-.L2 .L3: Because .L3 and .L2 are in different sections. - Justin On Thu, Jun 26, 2014 at 2:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > This reduces to > > .section .foo > .L1: > .L2 = .L1 > .section .bar > .long .L1-.L2 > > > Which is fairly

2010/10/27 Rafael Espíndola <rafael.espindola at gmail.com> > 2010/10/27 Xinliang David Li <xinliangli at gmail.com>: > > Thanks. Just built clang and saw the meta data and annotations on the > memory > > accesses -- is any opt pass consuming the information? > > The tests in test/Analysis/TypeBasedAliasAnalysis suggest that at > least licm is using it.

SHA1 in LLVM is *very* naive, any improvement is welcome there! It think Amaury pointed it originally and he had an alternative implementation IIRC. — Mehdi > On Nov 16, 2016, at 3:58 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > By the way, while running benchmark, I found that our SHA1 function seems much slower than the one in gold. gold slowed down by

----- Original Message ----- > From: "Renato Golin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rafael Espíndola" <rafael.espindola at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, February 10, 2016 7:50:33 AM > Subject: Re: [llvm-dev] [RFC] Lanai backend > > On 10 February 2016 at 13:42,

On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >> >> On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> But gold has at most 2 objects loaded at any time. >> >> Are you sure about

On Mon, Nov 23, 2015 at 3:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 23 November 2015 at 15:11, Aaron Ballman <aaron.ballman at gmail.com> wrote: >> On Mon, Nov 23, 2015 at 3:07 PM, Rafael Espíndola >> <rafael.espindola at gmail.com> wrote: >>>> We appear to use both system_temp_directory(true) and >>>>

The current implementation was “copy/pasted” from somewhere (it was explicitly public domain). > On Nov 16, 2016, at 4:05 PM, Rui Ueyama <ruiu at google.com> wrote: > > Can we just copy-and-paste optimized code from somewhere? > > On Wed, Nov 16, 2016 at 4:03 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > SHA1 in LLVM is

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back. Best regards, George.

Hi, I am new to LLVM and have been trying to get it working on scratchbox (ARM target). When I try to build llvm-2.1, the build freezes with the following output.. /scratchbox/compilers/arm-softfloat-linux-gcc-3.4.4-cs-2005q3-2-glibc-2.3.6/bin/sbox-arm-softfloat-linux-gnu-nm: 'libgcc/./_dvmd_lnx_s.o': No such file mv -f libgcc/./_dvmd_lnx.visT libgcc/./_dvmd_lnx.vis

Glad to hear you can reproduce it. What I don't know is if this is a linker issue or an LLVM issue. -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Friday, May 30, 2014 3:58 PM To: Daniel Stewart Cc: LLVM Developers Mailing List Subject: Re: Error with Gold Linker during LTO Sorry, I had understood that the linker was crashing, not the

OK, thank you. Are there some pre-built X86 binaries for LLVM-gcc for ARM? It yes, where can I download from? Thank you, Corina --- On Sun, 1/17/10, Rafael Espindola <espindola at google.com> wrote: From: Rafael Espindola <espindola at google.com> Subject: Re: [LLVMdev] LLVM-gcc for ARM To: "corina s" <corina_fff at yahoo.com> Cc: llvmdev at cs.uiuc.edu, anton at

Thanks. Just built clang and saw the meta data and annotations on the memory accesses -- is any opt pass consuming the information? By the way the build instruction in this page http://clang.llvm.org/get_started.html needs to be updated -- it recommends config (with default settings) and build llvm in the source dir -- it leaves some 'sticky' generated files in the source dir leading to