[PATCH] D122939: [NVPTX][tests] Do not run the test CodeGen/Generic/2010-11-04-BigByval.ll

[Igor Chebykin via Phabricator via llvm-commits]

i-chebykin added a comment.

In D122939#3423407 <https://reviews.llvm.org/D122939#3423407>, @tra wrote:

> Does it mean that the test will be disabled for everyone with NVPTX back-end compiled in?

yes

> That would not be the right thing to do, IMO.
>
> While I agree that this particular test does not add much to NVPTX testing, I think we still may want it to run.
>
> I'm also quite puzzled about `unacceptable run time when using XFAIL` and what NVPTX has to do with it. Are you saying that the test has unacceptable run time when NVPTX is the default architecture targeted by LLC?

yes, about ~1h for array [65535 x i8]

> Perhaps a better approach would be to run llc with explicit triple(s). It would have the benefit of making the test agnostic of the host or build options.

Some more info:

- The test uses the type: %big = type [131072 x i8] for functions’ by value param
- The llc crashes with arg_size >= 65536 in pass 'NVPTX DAG->DAG Pattern Instruction Selection' with failed assertion `NumValues == VTs.NumVTs && "NumValues wasn't wide enough for its operands!"'
- The test crashes after ~1h run time
- The class SDNode used during IR generation uses "unsigned short NumValues", so the max values count can be 65535 only
- Anyway, NVPTX vectorizer did not vectorize the array load/store for nvptx triple, so there are load/store instructions for `every byte` (max count is 65535)
- So, the llc crashes with assert for array length 131072 (defined in the test)
- Other problem is that test run time is ~1h (on my machine) for array size 65535, this is too long
- NVPTX vectorizer expects the alignment of the data 16 bytes, but the alignment for vectorizer is defined by the data type of the array, not alignment of the function param
- Therefore, the current NVPTX should be substantially updated to support the testcase
- The x86 target successfully emit short code for the array load/store, it uses other path for vectorization


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122939