search for: arm1176jzfs

I've been playing around with using LLVM on one of our projects, which runs on an arm1176jzf-s processor. When compiling for Thumb, a couple of the generated assembly files end up with a 'ror.w' instruction, which is a Thumb2 instruction. Since arm1176jzf-s doesn't support Thumb2, the assembler then turns around and barfs on it. I don't have any experience with this

What would be the proper clang (3.2) options to generate ARM for Raspberry pi for LLVM 3.2 with clang 3.2? I realized that "-ccc-host-triple" is no longer valid option in clang. p.s. I googled and found the following which doesn't work with clang 3.2. To cross-compile for Raspberry Pi add flags -ccc-host-triple arm-eabi -marm -mfpu=vfp -mcpu=arm1176jzf-s -mtune=arm1176jzf-s

Hi Matt, You're absolutely right, that pattern should definitely have an "only-in-Thumb2" predicate attached. Do you have commit access? Also, if you have a reduced test case, that would be awesome, but the patch is correct as-is even if not. -Jim On Jul 2, 2012, at 8:05 AM, Matt Fischer <mattfischer84 at gmail.com> wrote: > I've been playing around with using LLVM

I went ahead and committed it, along with a basic test case, in svn r159538. On Jul 2, 2012, at 9:34 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Matt, > > You're absolutely right, that pattern should definitely have an "only-in-Thumb2" predicate attached. > > Do you have commit access? Also, if you have a reduced test case, that would be awesome, but

Targetting the raspberry pi, what triple/flags should I set? I tried triple: armv4t-unknown-linux-gnueabi and ld fails with: a.out uses VFP register arguments if i set hardfloat (using optdata.FloatABIType = FloatABI::Hard), ld fails with an assertion: 2.22 assertion fail ../../bfd/elf32-arm.c:11477 what am I missing?

It depends, of course, what operating system you have installed on the RPi, but given that it's an ARM1176JZFS (ARMv6) chip, I would expect to see armv6, not armv4t, in the CPU part of the triple. It has a VFP unit, so I'd assume that you'd want to set hardfp (unless you installed an OS that doesn't support hardfp in its standard library), but if ld is complaining then you almost certainly have...

Hey Everybody, A little while ago I posted an RFC( http://lists.llvm.org/pipermail/llvm-dev/2017-July/115666.html) with the proposition of adding a new outliner at the IR level. There was some confusion and many questions regarding the proposal which I’d like to address here: Note about nomenclature: Candidate: A repeated sequence of instructions within a module. Occurrence: One instance

In general I would love to see an outliner at the IR level also. But rather than a comparison vs. the machine outliner I would like to learn more about how the core data structures between the outliners will be shared. In particular for matching/pruning it seems to be a reasonable approach. A few more remarks/questions are below also. Thanks Gerolf > On Sep 5, 2017, at 4:16 PM, River Riddle

I've been playing around with using LLVM on one of our projects, which runs on an arm1176jzf-s processor. When compiling for Thumb, a couple of the generated assembly files end up with a 'ror.w' instruction, which is a Thumb2 instruction. Since arm1176jzf-s doesn't support Thumb2, the assembler then turns around and barfs on it. I don't have any experience with this

Hey Gerolf, On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > In general I would love to see an outliner at the IR level also. But > rather than a comparison vs. the machine outliner I would like to learn > more about how the core data structures between the outliners will be > shared. > The only structure that needs to be shared is a

> On Sep 21, 2017, at 8:02 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hey Gerolf, > > On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote: > In general I would love to see an outliner at the IR level also. But rather than a comparison vs. the machine outliner I would like to learn more

llvm-toolchain-3.8 seems to have problems on debian armel and raspbian. On raspbian it builds but our armv7 contamination checker blocked it from entering the repo. Further investigation showed that "compiler-rt" was being built with -march=armv7 . I was able to remove the -march with some build-system hacker but then I got a failure on

Hello. For our project needs we implemented a custom calling convention. The main goals are to pass function arguments in registers and always use tailcall optimization for calls to functions with our CC when applicable. Function arguments are always pointers and the maximum number of arguments is 5. No frame pointer register is in use for this CC. No varargs. Finally, there are not any

On 17/05/16 18:07, Tim Northover wrote: > Yes, it looks like we'd need to conditionally compile these functions > in ARM mode and use the v6 barrier instead of dmb ("mcr p15, #0, r0, > c7, c10, #5" I believe) to support the ARM1176JZF-S in RPi. You'd > probably also want the build system to use an explicit -march=armv6 or > something so you're not at the mercy

Raspberry Pi 1 and Zero use the arm1176jzf-s chip which AFAIK doesn't support NEON intrinsics. This may be a bug with the configure script because it appears to be compiling with NEON enabled. Lifeng can you comment? Is there a way to override the CPU detection in this case? Samuel, as a workaround you can download and compile an older version of the library. I think 1.1.2 predated the NEON

I wanted to roughly benchmark how the different version of libopus performed at each complexity level for a 6kbit/s output opus file. This was conducted on a Raspberry Pi so it is a constant hardware platform. This was done on an early Pi so only 256MB RAM but it was never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was

I think that, given previous discussion on the topic, we might want a split like this: (1) Search structure Suffix tree or suffix array. (2) Numbering/mapping/congruence scheme Every outliner should implement a function that maps instructions (or whatever structure you want to outline, crazy thoughts…) to integers. That should be passed to the search structure, which will return a list of

Hi All, What would be interesting would be a plot of complexity versus subjective or object audio quality. I've not had a chance to look at the new analysis code in 1.1 so maybe in the case of a 6kbps compression you could clarify what decisions would it be making that would justify the extra complexity? Best Regards Cliff Parris -----Original Message----- From: opus-request at

I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. I have shared a google sheet which has the raw data and charts for 6,16 and 32 kbps. Unfortunately you cannot show proper error bars on Google sheets but the standard deviation is in the data if you want to look. You can see that the profile for 1.1 is a lot different

Hi Tim, Thank you for your reply. Actually, I already played with various target triples including what sys::getProcessTriple() returns when I tried to compile it on a Raspberry Pi 3 device. Yes, changing the triple to armv7-unknown-linux-gnueabi changes the emitted return instruction to 'bx lr'. But this is not the issue. Let me describe it based on an example I prepared to demonstrate