search for: divacki

hi! To continue the inflow of good news this week, let me announce that clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! This includes things like booting kernel, gnu libstdc++, clang/LLVM itself and many other components that make up FreeBSD operating system. I personally consider this a milestone where -integrated-as should become the default for ELF/{x86_64,i386}. Many

I'm working on Position-independent code for 32-bit PowerPC, but running into a problem. At the beginning of each function, there's a pre-word that's the difference between the PICBase (.L1$pb) and the GOT. This works fine when generating assembly output, but it fails when generating ELF output, with the error "Cannot represent a difference across sections" (line 847,

Tim, How about the below option ? 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's

On Oct 29, 2010, at 8:45 AM, Roman Divacky wrote: > hi! > > To continue the inflow of good news this week, let me announce that > clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! > > This includes things like booting kernel, gnu libstdc++, clang/LLVM > itself and many other components that make up FreeBSD operating system. > > I personally consider

Hi Divacky, I have an armv7 variant that supports hardware division (extension). For my variant, I use ".cpu cortex-a9" and division attribute(.eabi_attribute 44, 2 @ Tag_DIV_use) to let the assembler do the right thing if it encounters a division instruction. With your path, the .cpu directive is used to fetch the available features of a CPU and ignores the eabi attributes. What

Hi, In FreeBSD, we aim for replacing gcc with clang. We can compile all of the base system except the loader which does not fit within the hardware limits (7680 bytes). Currently (r127066) clang/llvm is missing the target by 5 bytes. Thus it's 5 bytes from us being able to compile all of FreeBSD with clang (and replace gcc with clang). There's #6627

Hi there! The attached patch fixes a few places where 32bit register classes or instructions are used on PowerPC64. This lets me compile a working "vim" at -O0 on PowerPC64/FreeBSD. Previously it would crash the compiler with llvm_unreachable("Impossible reg-to-reg copy"); As it was mixing 64 bit registers with 32bit ones. Vim compiled with -O2 still crashes. OK

Hi, Target overrides of processFunctionBeforeFrameFinalized() are misused in two cases (MBlaze and PowerPC) to set the offsets of objects. Unfortunately this has no effect because the offsets are immediately reset by calculateFrameObjectOffsets(). The PowerPC backend does this to setup the stack frame layout according to the ABI. Ie. it spills the registers etc. in a fixed layout. How to do

Attached. You can also find it at http://people.freebsd.org/~jhibbits/hello_llvm.s . - Justin On Thu, Jun 26, 2014 at 1:26 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > > Sent from my iPhone > >> On Jun 26, 2014, at 12:33, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote: >> >> I'm working on Position-independent code for

On 29 January 2015 at 03:36, Tim Northover <t.p.northover at gmail.com> wrote: > These ought to be unneeded if you do 1+2 above. As far as I remember, .arch_extension does change the assembler flags to support whatever you set. Have you tried that? cheers, --renato

I have pushed the patch here: http://reviews.llvm.org/D7316 Review it and let me know. --Sumanth G > I have tried ".arch_extension" and it works perfectly fine for me. > I will move ahead and add the arch_extension framework to ARM. > > Thanks for your guidance guys. > --Sumanth G > -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org]

Hello LLVM People, Welcome to LLVM 3.0! Get it here: http://llvm.org/releases/ or read about it: http://llvm.org/releases/3.0/docs/ReleaseNotes.html This release represents approximately 6 months of development over LLVM 2.9, and delivers a large number of improvements. Some of the bigger leaps include a new register allocator (which can provide substantial performance improvements in

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering

On Wed, Jan 18, 2012 at 10:51:38PM +0400, Konstantin Tokarev wrote: > > > 18.01.2012, 02:46, "David Fang" <fang at csl.cornell.edu>: > > Hi, > > ?????????For anyone who might be interested, I've thrown together a little > > page to track my builds of llvm and clang, both release 3.0 and > > svn-trunk, on powerpc-darwin8. > > > >