similar to: [LLVMdev] ARM Integrated Assembler

I don't have any real say in this. It should be decided by folks who are working on ARM / ELF such as yourself. If you collectively feel it's ready to make the switch then I don't have any objections. Evan On Dec 10, 2013, at 6:26 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi Jim/Evan, > > We had this discussion last year, and I think it's time we

On 10 December 2013 15:00, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Dec 10, 2013 at 02:26:53PM +0000, Renato Golin wrote: >> In a nutshell, it seems to be our consensus that the integrated >> assembly can now be turned on by default on ARM, and we should add >> -no-integrated-as for the cases where it fails (like the kernel). > > It

On Tue, Dec 10, 2013 at 03:26:56PM +0000, Tim Northover wrote: > On 10 December 2013 15:00, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > > On Tue, Dec 10, 2013 at 02:26:53PM +0000, Renato Golin wrote: > >> In a nutshell, it seems to be our consensus that the integrated > >> assembly can now be turned on by default on ARM, and we should add > >>

On Tue, Dec 10, 2013 at 02:26:53PM +0000, Renato Golin wrote: > In a nutshell, it seems to be our consensus that the integrated > assembly can now be turned on by default on ARM, and we should add > -no-integrated-as for the cases where it fails (like the kernel). It can't assemble basic PIC code as created by clang -S for ELF platforms. That's IMO a pretty big show stopper.

FWIW, I also agree with Joerg that it would be very poor form to turn on -integrated-as when it can't even eat its own output. This has bitten me before (had to pass -no-integrated-as to reassemble .S output). I would really like to see it turned on in 3.4 however (just with fixes in place)! On 11 December 2013 08:16, Renato Golin <renato.golin at linaro.org> wrote: > On 10

On 10 December 2013 22:46, Chris Lattner <clattner at apple.com> wrote: > I’m pretty certain that the integrated assembler is already on for darwin/arm. Ah, in that case, ignore my point. ;) Thanks for all your comments, I'll make the changes now and lets see how things go. thanks, --renato

On 10 December 2013 21:48, Evan Cheng <evan.cheng at apple.com> wrote: > I don't have any real say in this. It should be decided by folks who are working on ARM / ELF such as yourself. If you collectively feel it's ready to make the switch then I don't have any objections. Thanks Evan! I wanted to make sure there were no issues on Darwin, as I really don't get to play

On 10/10/13 22:01, Jakob Stoklund Olesen wrote: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >> One of the issues the LLVMLinux project is having is with the use of >> named registers in the Linux kernel code. The kernel uses something like >> this in order to assign a C variable name to a register (one for each >> kernel

I'd like to announce the LLVMLinux project. This project aims to fully build the Linux kernel using Clang/LLVM on the various architectures supported by the Linux kernel. The project consolidates the work of the lll-project, the PAX team, and Mark Charlebois' work on the ARM kernel. http://llvm.linuxfoundation.org <http://llvm.linuxfoundation.org/> The hope is that this project

On 20/10/2013 16:22, Behan Webster wrote: > On 10/10/13 22:01, Jakob Stoklund Olesen wrote: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses something like >>> this in order to

On Dec 10, 2013, at 2:19 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 10 December 2013 21:48, Evan Cheng <evan.cheng at apple.com> wrote: >> I don't have any real say in this. It should be decided by folks who are working on ARM / ELF such as yourself. If you collectively feel it's ready to make the switch then I don't have any objections. > >

In an earlier email[1] I proposed adding support for the ldr pseud-instruction to the ARM integrated assembler. After some discussion the overall consensus seemed to be that it was worth adding. One concern was that we needed to have adequate testing. I promised to provide more details on what the behavior should be and provide some tests before starting the implementation. The FileCheck-ified

On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > One of the issues the LLVMLinux project is having is with the use of > named registers in the Linux kernel code. The kernel uses something like > this in order to assign a C variable name to a register (one for each > kernel arch). > > register unsigned long current_stack_pointer

Hi Tom, I've got a few patches that I'd like to get into 3.5.2 if I can. * r230235 - [mips] Honour -mno-odd-spreg for vector insert/extract when MSA is enabled. o Fixes a failure in the test-suite when -mno-odd-spreg and -mmsa are used together. * r227089 - [mips] Enable arithmetic and binary operations for the i128 data type. o This fixes an instruction selection

One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define

I have attached an initial patch that implements the ldr pseudo. It still needs some clean up and more tests, but I would like some feedback on the approach I used and if there are any objections to implementing it this way. Here is my approach: Add a finishParse() callback to the target asm parser This callback is invoked when the parse has finished successfully. It will be used to write out

Hi all, I'm trying to generate whole program bitcode files for linux kernel and do interprocedural analysis on kernel. I use llvmlinux to compile kernel with clang and generate a bunch of bitcode files successfully. I need to link all these bitcode files together into a single bitcode file, so that I can run whole program analysis. Can I use llvm-link to achieve this? Or should I use

Hi Eric, It's the unsolved problems on the pass-MCTargetOptions-everywhere path that are my main concern with that approach rather than the amount of work. The first problem is that the result of IRObjectFile::CollectAsmUndefinedRefs() depends on the ABI but IRObjectFile doesn't know it. How would you deliver the ABI to IRObjectFile? The second problem is that IRLinker will link

On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in

Hi David, In these examples, I don’t see the directive that indicates where the assembler should place the constant pool? -Jim On Nov 1, 2013, at 11:16 AM, David Peixotto <dpeixott at codeaurora.org> wrote: > In an earlier email[1] I proposed adding support for the ldr > pseud-instruction to the ARM integrated assembler. After some discussion the > overall consensus seemed to be