similar to: [LLVMdev] __clear_cache on arm

On Jun 22, 2011, at 7:22 AM, Renato Golin wrote: > On 22 June 2011 14:33, Damjan Marion <damjan.marion at gmail.com> wrote: >> Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. > > Indeed, this is new in ARM ARM v7. > > >> Can we change to

On Jun 22, 2011, at 3:16 PM, Renato Golin wrote: > On 22 June 2011 11:49, Damjan Marion <damjan.marion at gmail.com> wrote: >> # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c > > Even though you specified cpu as arm9, it's probably generating > generic ARM IR (use -emit-llvm -S and see), which defaults

On Jun 22, 2011, at 5:29 PM, Jim Grosbach wrote: > > On Jun 22, 2011, at 7:22 AM, Renato Golin wrote: > >> On 22 June 2011 14:33, Damjan Marion <damjan.marion at gmail.com> wrote: >>> Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. >>

On 22 June 2011 14:33, Damjan Marion <damjan.marion at gmail.com> wrote: > Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. Indeed, this is new in ARM ARM v7. > Can we change to old mnemonic at least when ARMv4 and ARMv5 code is generated? We definitely should.

On 22 June 2011 11:49, Damjan Marion <damjan.marion at gmail.com> wrote: > # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c Even though you specified cpu as arm9, it's probably generating generic ARM IR (use -emit-llvm -S and see), which defaults to ARM instructions. If you want thumb, use triple =

On Jun 22, 2011, at 4:02 PM, Damjan Marion wrote: >> >> To get -integrated-as working so that we don't need to go through the assembler at all should be mostly a matter of bug fixing, modulo inline assembly support. For non-trivial inline assembly, and to get a system assembler replacement based on the MC assembler, it'll be a bigger task. The ARM asm parser is currently in

On Jun 23, 2011, at 1:13 AM, Jim Grosbach wrote: > On Jun 22, 2011, at 4:02 PM, Damjan Marion wrote: >>> >>> To get -integrated-as working so that we don't need to go through the assembler at all should be mostly a matter of bug fixing, modulo inline assembly support. For non-trivial inline assembly, and to get a system assembler replacement based on the MC assembler,

Hi, I just realized that clang produces Thumb-2 instruction in code even when older CPU type which doesn't suport Thumb-2 is specified. Here is output: # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c clang version 3.0 (http://llvm.org/git/clang.git 98138cdfdee05c0afbab2b209ce8cfe4a52474e1) Target: arm-unknown-freebsd Thread

projects/compiler-rt/lib/builtins/clear_cache.c I suggest two small changes here. 1. Mark it however required to avoid inlining, i.e. for the x86/amd64 case. Control transfer is required. I realize it is likely anyway, you aren't likely to "fall from" the caller into the code. 2. #elif defined(_WIN32) && (defined(__arm__) || defined(__aarch64__)) be changed to just: #elif

Hi all I received the following patch for compiling ctypes module for Python on FreeBSD from Keith White (I'm in no position to judge this fix, I'm just passing it on). Is there anyone on this list being able to commit this code? Thxs, Werner =================================================================== --- contrib/compiler-rt/lib/clear_cache.c (revision 250739) +++

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

builtins/clear_cache.c depends on kernel headers. It's difficult to ascertain whether it's mixing with libc headers but if it is then that's a bug in its own right. Either way, it's pulling in kernel headers for a single #defined constant that's been part of the linux ABI for years now. This makes it more difficult to cross compile for, in my opinion, no good reason. So

Folks, To implement this bug: http://llvm.org/bugs/show_bug.cgi?id=19142 I need an LLVM intrinsic to communicate the need to lower the builtin wither to noop or a call or even a sequence of instructions. I thought about: void @llvm.clear_cache(i8 * begin, i8 * end) to simulate precisely GCC's builtin: void __builtin___clear_cache (char *begin, char *end) which will be, by default,

On Jun 23, 2011, at 12:01 AM, Jim Grosbach wrote: > > On Jun 22, 2011, at 2:08 PM, Renato Golin wrote: > >> On 22 June 2011 19:18, Anton Korobeynikov <anton at korobeynikov.info> wrote: >>> Unfortunately, you have to live with this. Until recently binutils >>> were quite buggy wrt thumb2 code, so, most probably you will need new >>> binutils in

On Jun 22, 2011, at 10:03 AM, Damjan Marion wrote: > > On Jun 22, 2011, at 6:15 PM, Jim Grosbach wrote: > >> >> On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: >> >>> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>>>> This sounds like a dead end as newer binutils are GPLv3. >>>> >>>> Yeah,

Hello, I wanted to make sure that my boot slowdown was related to space_cache so I rebooted the PC several times and it did become slower again. What is more, it doesn''t seem like I even need to generate any actual IO traffic to trigger this. I thought I might give clear_cache a shot again and to test the boot speed with nospace_cache as well. After first booting with

Rename no_space_cache option to nospace_cache to be more consistent with the rest, where the simple prefix ''no'' is used to negate an option. The option has been introduced during the -rc1 cycle and there are has not been widely used, so it''s safe. Signed-off-by: David Sterba <dsterba@suse.cz> --- fs/btrfs/super.c | 4 ++-- 1 files changed, 2 insertions(+), 2

Hi; This is on Linux/x86-64, I get this at stage1: make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' Makefile:6: make/config.mk: No such file or directory Makefile:7: make/util.mk: No such file or directory Makefile:16: *** Refusing to build with empty ProjObjRoot variable. Stop. make[2]: Leaving directory

Hi All, I just wanted to let you know that libc++ and compiler_rt and now dual licensed under *both* the UIUC and MIT license. The reason for this is that the UIUC license (like many BSD licenses) requires that binaries that link LLVM code contain a notice that they are derived from LLVM. This clause doesn't make sense for libraries like libc++ and compiler_rt: these get implicitly added to

> On Jul 29, 2016, at 2:19 AM, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > > On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer