search for: larrabee

...> SSE and AVX > SIMD instructions under one framework. I'll leave MMX and 3dNow > alone since > they're oddballs and hardly anyone uses them. I don't want to unnecessarily expand your scope, but while you're doing this, it might make sense to keep in mind the new Larrabee instructions as well. They operate on 512-bit registers, and there's a (slightly indirect) reference available here: http://software.intel.com/en-us/articles/prototype-primitives-guide/ I'm not suggesting adding these now, just that they might be interesting to keep in mind while yo...

...e in situations where you can also have > > vectors of pointers. > > Vectors of pointers are not allowed. I think disallowing intptr in > vectors makes perfect sense. Then we're going to need to fix this in the IR fairly soon. We won't be able to support architectures like Larrabee nicely until we do. -Dave

...to a lot of bother adding hardware to perform dynamic rescheduling and register renaming, which effectively replace these stack accesses with registers or access to fast cache. But, with upcoming architectures - particularly ones with a very large number of cores (e.g. something along the lines of Larrabee, or Ambric, and a plethora of others) - such hardware is too costly. As a result, needless stack activity consumes available memory bandwidth, which absolutely hammers instruction-level parallelism. I certainly agree that a fast default register allocator is the best strategy for LLVM, considering...

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

...target but that's true independent of vector types. Scalar optimizers want to know about targets too. > As far as I am aware not a single one of any of the above types of > instruction sets allows the "subscripting" of packed data within a > register Given what we know of Larrabee and speculating that the "Knights" family is likely a derivative of it, it's safe to assume that future Intel architectures will be much more like traditional vector machines. That means gather/scatter, element indexing, etc. The existing PINSR/PEXTR and shuffle instructions already...

On Nov 12, 2009, at 7:35 PM, Talin wrote: > On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> > wrote: > > There is also the issue of how constants should be represented. > > For all current processors that I know of, an intptr will be either > 32 or 64 bits. However, there may be some future processor which > supports 128-bit pointers

Andrew, your response highlights a naming problem in LLVM, which is that "array" and "vector" mean the same thing in normal computer language and compiler theory usage, so it is inconvenient and misleading within LLVM to give one a very specific meaning that is different from the other.... to the LLVM developers I would suggest using the term

Hi, I've done work on predicated SIMD representations for LLVM. If you search through the archives, you may find my "applymask" proposal, which is an attempt at representing predication in a very comprehensive way. I've since stopped pushing the proposal in part because Larrabee's changing fortunes led to a decline of interest at the time, in part because the proposal doesn't look intuitive to people who don't have experience in SIMD programming, and in part because there were some technical details with my actual proposal (although I believe solutions could be...

Hello, I'm working on a compiler based on LLVM for a SIMD architecture that supports instruction predication. We would like to implement branching on this architecture using predication. As you know the LLVM-IR doesn't support instruction predication, so I'm not exactly sure on what is the best way to implement it. We came up with some ways to do it in LLVM: - Do not add any