uweigand wrote: > Improved handling to utilize vector instructions when present.
Thanks! >New VR16 regclass, but v8f16 _not_ legal. It might make sense to have it as a >legal type and e.g. do VL;VST when moving vectors in memory, and also set all >vector ops to "Expand". Not sure how trivial that change would be, given some >special handlings of vector nodes, so not done as of now: only the scalar f16 >is legal. Agreed. I don't think we need vector f16 at this point. > Without vector support, it might make sense to have load/store pseudos with > an extra GPR def operand, so that these loads/stores can be expanded as a > PostRA pseudo. Then it would only need handling in one place, but OTOH having > a second explicit def operand is also undesired, maybe. I don't think we need to spend much effort optimizing for pre-z13 machines at this point. > f16 immediates handled like f32: > > * Basic support added for fp 0.0/-0.0 and generation of vector constants > (which should always work btw given their size with vrepih). > > * Single-lane vector instructions like WFLCSB not used for fp16 (yet), > even though it should be possible to add _16 variants. Doesn't seem > important, so skipping. The sign-operations are the only instructions we even could semantically use with f16, right? We certainly could do so, but I agree it's probably not important. > Should fp16 inline asm operands also be supported at this point? Good point. I think so, yes. Also, looks like the clang-format check is complaining a bit ... https://github.com/llvm/llvm-project/pull/109164 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
