Bitcast only really applies between scalars and vectors. Implement as
an unmerge and remerge. The test needs to tolerate failure since one
of the unmerges currently fails to legalize.
Details
Diff Detail
Event Timeline
I think this is a verifier bug. You're not allowed to bitcast between scalar pointers and scalars, so allowing it for vectors doesn't make much sense. I think allowing this is potentially problematic for non-integral pointers since it makes it easy to accidentally launder away the pointerness
We don't have an alternative way to easily convert between them though. Unless G_PTRTOINT is also allowed to take vectors of pointers.
G_PTRTOINT works with vectors. I'm not opposed to allowing G_BITCAST between scalar and (integral) pointers, although this differs from the IR. It makes more sense in codegen to have these be more flexible. The current state doesn't make sense though. We can either:
- Allow casts between pointers and others types. This will need documenting as differing from the corresponding IR instructions. This should also maybe restrict this for nonintegral address spaces?
- Disallow bitcast between vectors of pointers and vectors of scalars and match the IR
Ah, I didn't realize it was allowed in the IR. In that case AArch64 can move to using that instead.
- Allow casts between pointers and others types. This will need documenting as differing from the corresponding IR instructions. This should also maybe restrict this for nonintegral address spaces?
- Disallow bitcast between vectors of pointers and vectors of scalars and match the IR
Without a clear need maybe we should err on the conservative side and keep the semantics restricted and matching the IR when possible. If we have to revisit this in future we can do.
On the topic of this particular change: IIRC the semantics of bitcast is that it's equivalent of doing a store of the source type and a load of the dest type, which can have differing results on big endian targets. Is this lowering code safe in that case?