[PATCH] D126461: [RISCV] Extract and store new vl of vleff/vlsegff iff destination isn't null

Craig Topper via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 20 21:10:00 PDT 2022


craig.topper added a comment.

In D126461#3596761 <https://reviews.llvm.org/D126461#3596761>, @reames wrote:

> Despite the comments above, the purpose of this patch remains unclear.
>
> Per the draft spec, the relevant wording is:
> "These instructions execute as a regular load except that they will only take a trap caused by a synchronous exception
> on element 0. If element 0 raises an exception, vl is not modied, and the trap is taken. If an element > 0 raises an
> exception, the corresponding trap is not taken, and the vector length vl is reduced to the index of the element that would
> have raised an exception."
>
> Working through the scenario in this patch with the destination being null, the expected result is for a trap to be generated (provided null is unmapped of course), and VL not to be modified.  In order for this change to make any difference in runtime behavior, the value passed must be null (or otherwise guaranteed to fault).  It seems very odd to me that we are modifying code which only runs after an instruction which is guaranteed to fault.  Is there an assumed runtime here which is e.g. restarting execution?

`dst` in the patch description is not the pointer being loaded, it's the pointer of where to store the new_vl. That is only thing being checked for null in this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126461/new/

https://reviews.llvm.org/D126461



More information about the cfe-commits mailing list