pcwang-thead added a comment. In D126461#3597862 <https://reviews.llvm.org/D126461#3597862>, @craig.topper wrote:
> 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. Thanks for your kind explanation! @craig.topper I did this change just because previous GCC implementation have done null pointer checking. Some of our codebases crashed when we switched to LLVM because new_vl is set to NULL to ignore output new vl. : ) @reames Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126461/new/ https://reviews.llvm.org/D126461 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
