| commit | 947f78ac27f4ea52a443ba9d5983cfe3eaf51148 | |
| author | Ulrich Weigand <ulrich.weigand@de.ibm.com> | |
| Wed, 6 May 2020 18:42:46 +0000 (6 20:42 +0200) | ||
| committer | Ulrich Weigand <ulrich.weigand@de.ibm.com> | |
| Wed, 6 May 2020 19:15:58 +0000 (6 21:15 +0200) | ||
| tree | 5573f9b01ed659b5cfbf96676c042080f5489744 | treesnapshot (tar.gz zip) |
| parent | f21c704553a8af7012eaf1ab777e2aa1a55cc86d | commitdiff |
[SystemZ] Fix/optimize vec_load_len and related intrinsics
When using vec_load/store_len_r with an immediate length operand
of 16 or larger, LLVM will currently emit an VLRL/VSTRL instruction
with that immediate. This creates a valid encoding (which should be
supported by the assembler), but always traps at runtime. This patch
fixes this by not creating VLRL/VSTRL in those cases.
This would result in loading the length into a register and
calling VLRLR/VSTRLR instead. However, these operations with
a length of 15 or larger are in fact simply equivalent to a
full vector load or store. And in fact the same holds true for
vec_load/store_len as well.
Therefore, add a DAGCombine rule to replace those operations with
plain vector loads or stores if the length is known at compile
time and equal or larger to 15.
When using vec_load/store_len_r with an immediate length operand
of 16 or larger, LLVM will currently emit an VLRL/VSTRL instruction
with that immediate. This creates a valid encoding (which should be
supported by the assembler), but always traps at runtime. This patch
fixes this by not creating VLRL/VSTRL in those cases.
This would result in loading the length into a register and
calling VLRLR/VSTRLR instead. However, these operations with
a length of 15 or larger are in fact simply equivalent to a
full vector load or store. And in fact the same holds true for
vec_load/store_len as well.
Therefore, add a DAGCombine rule to replace those operations with
plain vector loads or stores if the length is known at compile
time and equal or larger to 15.