Page MenuHomePhabricator

[VE][isel] Map EVT vectors to vector registers.
Needs ReviewPublic

Authored by simoll on Dec 23 2020, 3:09 AM.

Details

Summary
  1. Let targets specify their own conversion for EVTs.
  2. Use this to map (almost all) vector EVTs to vector register for the VE target. Also use this across function calls in the 'fastcc'.

Without this patch, isel scalarizes "weird" vector types such as <17 x i16>. This is not really an option for long-vector architectures such as SX-Aurora. This patch adds a custom callback to let the target decide to map also those EVTs to vector registers.

Diff Detail

Event Timeline

simoll created this revision.Dec 23 2020, 3:09 AM
simoll requested review of this revision.Dec 23 2020, 3:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 23 2020, 3:09 AM
simoll updated this revision to Diff 313533.Dec 23 2020, 4:26 AM

NFC. Removed stray comment.

FYI i have tested this against check-all with clang and all (including experimental) targets enabled.

simoll added a comment.Jan 8 2021, 2:53 AM

This is one of those patches that has the potential to linger on without review for 1Y+ .. let me know if there is anything i can do to get this reviewed, as it really helps with bringing good vector architecture (long SIMD) support to LLVM. Thanks.

arsenm added a comment.Jan 8 2021, 6:18 AM

This is one of those patches that has the potential to linger on without review for 1Y+ .. let me know if there is anything i can do to get this reviewed, as it really helps with bringing good vector architecture (long SIMD) support to LLVM. Thanks.

Can I interest you in moving to GlobalISel instead of trying to teach the DAG about new types :)

llvm/lib/CodeGen/TargetLoweringBase.cpp
942

don't need hasValue()

943

*CustomLK

This is one of those patches that has the potential to linger on without review for 1Y+ .. let me know if there is anything i can do to get this reviewed, as it really helps with bringing good vector architecture (long SIMD) support to LLVM. Thanks.

Can I interest you in moving to GlobalISel instead of trying to teach the DAG about new types :)

Definitely! GlobalISel sure has my interest and i am following the development closely. However, we have to make do with what we've got, which is dag-based downstream implementation. I see it that way: the quicker we get this in a stable state and expose the traditional way's intrinsic limitations, the closer we are to switching/contributing to global isel :)

simoll updated this revision to Diff 316060.Jan 12 2021, 4:40 AM
simoll marked 2 inline comments as done.
simoll edited the summary of this revision. (Show Details)

NFC. Usage of Optional. Rebased onto committed D93709 .