search for: vuzp

...sier for target-independent code > to understand. Yes, I have tried to do that as much as possible. There are still a number of operations where we've ended up using intrinsics, for varying reasons. For example, I had been planning to have the front-end translate the VTRN, VZIP, and VUZP builtins to vector shuffles, since that is exactly what they are. But, after discussing it with Evan, I changed these to intrinsics because we couldn't figure out a good way to handle them as shuffles. They take two vector operands and shuffle them in place, producing two vector resul...

Hi Bob, An alternative would be to model the operations as regular shuffle, load, and store operators, combined to describe the actual instructions. This would make them easier for target-independent code to understand. Dan On Aug 8, 2009, at 11:47 PM, Bob Wilson <bob.wilson at apple.com> wrote: > The ARM Neon load, store and shuffle operations that I've been >

On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote: > I really do think that bitcast is the right way to go here. I ran > into a couple of similar problems when bringing up the altivec port. > For example, at one time we'd get "all zero vectors" of different > MVTs, which would not be CSEd. > > The fix for this was to be really disciplined about what types to make

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. It

...te SSA values. How can this be done? The example given was a Hexagon-specific intrinsic that doesn't appear to make use of the two destinations at the IR level. - Are separate extratreal/extractimag intrinsics sufficient for targets that support such operations (e.g. NEON's VUZP)? - The proposal allows bitcasts of vector of complex, even though bitcasts of aggregates in general are disallowed. Is this special case reasonable? - If we allow such bitcasts, is czip necessary, or is shufflevector + bitcast to vector of complex sufficient? - Some frontends wil...

...is be done? The example given was a > Hexagon-specific intrinsic that doesn't appear to make use of the two > destinations at the IR level. > > - Are separate extratreal/extractimag intrinsics sufficient for targets that > support such operations (e.g. NEON's VUZP)? > > - The proposal allows bitcasts of vector of complex, even though bitcasts of > aggregates in general are disallowed. Is this special case reasonable? > > - If we allow such bitcasts, is czip necessary, or is shufflevector + bitcast > to vector of complex suf...