search for: ppc_f128

...tion selection LLVM is incredibly keen on putting values of those types in their 'correct' register class (e.g. XMM) in preference to the BNDx bounds registers. I haven't found any workaround for that, and adding an MVT code (where there is already precedent for oddballs like x86mmx and ppc_f128) seems to be low impact compared to any change to general register handling. As well, BNDx register contents do not really match the semantics of i128 or v2i64 or unfortunately even <2 x i8*>, though the last is an attractive candidate for an IR representation. As I mentioned, we do intend...

Hi Kevin, Thanks for working on this. We usually try really hard to avoid adding new types such as x86mmx. I don’t know the memory-protection instruction set at all but I imagine that you are not expecting other LLVM optimizations to interact with them right ? (it looks that way from this example[1]). If you are not accessing the individual components then you can use i128, or even <2 x

...is incredibly keen on > putting values of those types in their 'correct' register class > (e.g. XMM) in preference to the BNDx bounds registers. I haven't > found any workaround for that, and adding an MVT code (where there > is already precedent for oddballs like x86mmx and ppc_f128) seems > to be low impact compared to any change to general register > handling. > > As well, BNDx register contents do not really match the semantics > of i128 or v2i64 or unfortunately even <2 x i8*>, though the last > is an attractive candidate for an IR representation....

Hi all, I'm currently adding new instructions and registers to the X86 code generator for Intel Memory Protection Extensions [1]. A class of special-purpose registers BNDx each holds 2 x 64-bit values. The components are not individually readable or writable (except by going through memory) but there are instructions that read only one of the two elements. The two 64-bit values can be