similar to: [LLVMdev] Implementing the ARM NEON Intrinsics for PowerPC

Hello Hal, I am not very familiar with the DSP capabilities of PowerPC, but I imagine there will be instructions for simple vector operations like vector addition, multiplication, etc. so for these I imagine the implementation would consist of just outputting the correct instruction. However, for NEON instructions like the reciprocal step (see

Stan, Do you mean that you want to emulate the ARM NEON intrinsics on PowerPC? -Hal ----- Original Message ----- > > > Hello LLVM Devs, > > > Thanks for helping me previously to cross-compile for ARM, I managed > to get a working toolchain and am currently having fun compiling > different toy problems and running them on a pandaboard. > > As part of my

On 26 September 2013 17:52, Stanislav Manilov <stanislav.manilov at gmail.com>wrote: > To answer your question I am testing on a pandaboard currently, which has > an arm cortex-a9 processor, which I think is 64-bit. > Cortex-A9 is still 32-bits, so you'll have all support you need. ;) however it doesn't if I remove the -ffreestanding flag. I need to figure > this out

Hello Renato, It turned out I just didn't do the cross-compilation correctly, and Tim Northover already pointed me to a guide you have written on it ( http://clang.llvm.org/docs/CrossCompilation.html), so I will read that before continuing with my efforts. To answer your question I am testing on a pandaboard currently, which has an arm cortex-a9 processor, which I think is 64-bit. I am much

How does this make any sense? NEON intrinsics are there to support code generation targeting the ARM NEON SIMD unit on the ARM architecture. Power/PowerPC as it's own AltiVec/VSX SIMD units, which in turn has it's own intrinsics. If you want write code that explicitly targets CPU execution units it's necessarily tied to that specific CPU architecture. If you just want to test code

On 2 October 2013 12:17, Renato Golin <renato.golin at linaro.org> wrote: > On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > >> How does this make any sense? >> > > I have to agree with you that this doesn't make much sense, but there is a > case where you would want something like that: when the original source > uses NEON

On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > How does this make any sense? > I have to agree with you that this doesn't make much sense, but there is a case where you would want something like that: when the original source uses NEON intrinsics, and there is no alternative in AltiVec, AVX or even plain C. We encourage people to use NEON intrinsics,

Hello LLVM Devs, I am starting my PhD on Automatic Parallelization for DSP and want to play with some ARM NEON intrinsics for a start. I spent the last three days trying to compile a version of LLVM that would allow me to compile sources that contain these intrinsics, but with no success. In the process I found out that clang doesn't support NEON (as per

> To answer your question I am testing on a pandaboard currently, which has >> an arm cortex-a9 processor, which I think is 64-bit. >> > > Cortex-A9 is still 32-bits, so you'll have all support you need. ;) > Ah, Okay, embarrassing... however it doesn't if I remove the -ffreestanding flag. I need to figure >> this out next. >> > > Can you at

On 2 October 2013 13:36, Hal Finkel <hfinkel at anl.gov> wrote: > You can certainly do this in terms of an LLVM transformation, but I think > that creating some kind of header file would be, at least, where I'd start > prototyping this. > Yes, this is a good approach to understanding the problem. But I wouldn't use this as a final solution, as it scales quadratically

----- Original Message ----- > On 2 October 2013 12:17, Renato Golin < renato.golin at linaro.org > > wrote: > > > > > On 2 October 2013 10:12, Steven Newbury < steve at snewbury.org.uk > > wrote: > > > > > > How does this make any sense? > > > I have to agree with you that this doesn't make much sense, but there > is

Hi Philip, I forgot to mention that I was ignoring loop-independent dependences. If I don't I get an inconsistent, ordered, anti, loop-independent dependence and an inconsistent, ordered, flow, loop-carried dependence for example A. At the same time I get just a consistent, ordered, anti, loop-independent dependence for example B. Here's the .ll code for example A: *; Function Attrs:

Hi Philip, Thanks for checking! I'm running my own Foo pass that registers DependenceAnalysisWrapperPass as a prerequisite and then I run it like so: opt -load libfoo.so -foo example.bc This is LLVM 3.9. Cheers, - Stan On Wed, Jun 21, 2017 at 5:40 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Stan, > > in both cases I get a consistent anti result. Can you

On 2 October 2013 12:34, Stanislav Manilov <stanislav.manilov at gmail.com>wrote: > Again, the tool you describe is exactly what I ultimately want to create. > The translation to AltiVec would be a step towards understanding how to > manipulate the intrinsics, but it is not a goal on its own. > > Do you have any ideas where in the whole LLVM structure would it fit >

Oh, I see, that makes a lot of sense. How do I build the pass pipeline? On Thu, Feb 11, 2016 at 5:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Feb 11, 2016, at 9:49 AM, Stanislav Manilov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > I am used to specifying dependence on other LLVM passes in the >

On Wed, May 4, 2016 at 3:10 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > As in "look at the source of clang" or as in "look at the -S -emit-llvm" > output? If you mean the former, then would that be easy for someone who > hasn't seen the clang source before? > Generally the latter - then potentially set some breakpoints & look at

The usual advice I provide people is "see what Clang does with an equivalent C construct" On Wed, May 4, 2016 at 12:18 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > Hi, > > There is another benefit to keeping the CppBackend: it's great for > learning how to use the IR and the C++ API in particular, as can be seen > from this SO Q&A: >

Hello llvm-dev, I'm running a pass that uses the result of llvm::DependenceAnalysisWrapperPass to compute the dependencies between all instructions of a loop. I have the following two examples of code I wish to analyse: example A: ``` void move_one(int *A, unsigned n) { for (unsigned i = 0; i < n-1; ++i) { A[i] = A[i + 1]; } } ``` and example B: ``` void move_one_alt(int *A,

(Note: these are personal opinions rather than anything from my employer.) Although unusual, there might be circumstances in which it would make sense. | If you want write code that explicitly targets CPU execution units it's | necessarily tied to that specific CPU architecture. If you just want to | test code for written for a different CPU on a development box your best | bet is to use a

Hello, I am used to specifying dependence on other LLVM passes in the `getAnalysisUsage(AnalysisUsage &)` method of my pass. However, it doesn't seem that there is a header file that exposes the `mem2reg` pass - it is implemented in `Mem2Reg.cpp` as a wrapper. Is there an easy way to reuse this pass, or should I, in essence, duplicate `Mem2Reg.cpp` in my project? Cheers, - Stan