[PATCH][AArch64-BE] Be careful when replacing a BUILD_VECTOR with a MOVI

Asiri Rathnayake asiri.rathnayake at arm.com
Fri Aug 22 08:35:07 PDT 2014


Hi Tim,

Sorry for digging out this old discussion. I'm trying to re-work this patch
but I don't quite understand what you meant below:

> On 17 July 2014 18:10, James Molloy <james.molloy at arm.com> wrote:
>> Can I ping this please?

> I'm very uneasy about this one. It looks like it relies on the fact
> that the output of lowering a resolved BUILD_VECTOR is basically "(VT
> (bitconvert (f64 INST)))", which doesn't seem to be true in general.
> I'd have put the underlying flaw in the lax attitude to casting
> demonstrated by the *users* of this function, and said
> "0x0000ffff0000ffff" was an entirely reasonable output for <-1, 0, -1,
> 0> given how we're representing vectors.

I've been playing with this a little and it seems this representation can
produce invalid results in big-endian mode. For an example:

<dump>
@.str = private unnamed_addr constant [12 x i8] c"output: %d\0A\00", align 1

define i16 @f1(<4 x i16> %v1) nounwind {
   %e1 = extractelement <4 x i16> %v1, i32 0
   ret i16 %e1
}

define void @test() nounwind {
  %v1 = call i16 @f1(<4 x i16> <i16 -1, i16 0, i16 -1, i16 0>)
  %p2 = sext i16 %v1 to i32
  call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([15 x i8]* @.str,
i32 0, i32 0), i32 %p2)
  ret void
}
</dump>

In big-endian mode this results in 0 instead of -1 (expected). Did you meant
to say that we should keep this representation within the registers and only
reverse it when being pushed onto the stack for example?

Thanks.

- Asiri










More information about the llvm-commits mailing list