search for: birthpoint

...ent > transformations varies the type transformation based on what is using > the value. I don't know exactly how hard it would be, though... maybe > someone who's more familiar with the legalization infrastructure could > say more? Right, the type that needs to be used at the birthpoint of the value will generally be determined by the operation being performed to define it. At uses, that representation will have to be converted. There are some operations which may not provide a unique representation at a definition. Phi statements are the most obvious ones - if a phi sta...

On Tuesday 22 July 2008 08:33, Stefanus Du Toit wrote: > Right, the type that needs to be used at the birthpoint of the value > will generally be determined by the operation being performed to > define it. At uses, that representation will have to be converted. Why would this ever happen? If the mask doesn't match the vector length of the operation, isn't the operation undefined? I suppose a...

...the size of the operands being compared, and a selection requires a mask corresponding to the size of the operands being selected. The "simple" way to deal with this is to insert appropriate conversion code at uses of i1s, and pick a representation for a given i1 based on its SSA birthpoint. It's a little more ambiguous when you start adding phis into the mix, e.g.: a: %a1 = fcmp olt <2 x float> %f1, %f2 ; yields <2 x i1> br label %c b: %a2 = fcmp olt <2 x double> %d1, %d2 ; yields <2 x i1> br label %c c: %a3 = phi <2 x i1> [%a1, %a], [%a2,...

On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > 1) Vector shl, lshr, ashr > > I think these are no-brainers. We would like to extend the semantics > of the shifting instructions to naturally apply to vectors as well. > One issue is that these operations often only support a single shift > amount for an entire vector. I assume it

On Monday 21 July 2008 15:21, Stefanus Du Toit wrote: > We would like to extend the vector operations in llvm a bit. We're > hoping to get some feedback on the right way to go, or some starting > points. I had previously had some discussion on this list about a > subset of the changes we have in mind. Woohoo! We've been interested in talking about this for some time. >

Hi, We would like to extend the vector operations in llvm a bit. We're hoping to get some feedback on the right way to go, or some starting points. I had previously had some discussion on this list about a subset of the changes we have in mind. All of these changes are intended to make target-independent IR (i.e. IR without machine specific intrinsics) generate better code or be