This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Will higher bits of vector register be cleared to zero for `UADDLV` instruction?

Hi, 

   According to instruction guide,  `UADDLV` instruction will add every vector element in the source SIMD&FP register together, and writes the scalar result to the destination SIMD&FP register.

   My question is, what happens to the higher bits in the destination vector register? Are they deterministically cleared to 0, or not undefined (so unsafe to do any assumption)?

   The context for this ask, is that I'm seeing this codegen (https://godbolt.org/z/xjohrjocd), and in particular for the following sequence, not sure about the content in the higher 16 bits of register `s0`. Thanks for any inputs! 


uaddlv h0, v0.8b
fmov w9, s0
str x9, [x8]


Edit with more context

The example in godbolt link above is a little special, since the relevant function counts the number of bits that are set in a 64-bit integer; in other words, the number of bits is guaranteed to be no greater than 64, and a 16-bit integer is sufficient to store it.

Also, by `-print-after-all` of `llvm llc`, there are `undef` flags seen in a defined register. According to LLVM MachineOperand.h comments

/// IsUndef - True if this register operand reads an "undef" value, i.e. the
/// read value doesn't matter. This flag can be set on both use and def
/// operands. On a sub-register def operand, it refers to the part of the
/// register that isn't written. On a full-register def operand, it is a
/// noop. See readsReg().
 
So now it seems to me that higher bits could well be undefined, as opposed to being cleared to zero.
Parents Reply Children
No data