[llvm] [GlobalISel][AArch64] Legalize G_FABS and G_FNEG for SVE (PR #114784)

[Paul Walker via llvm-commits]

Thorsten =?utf-8?q?Schütt?= <schuett at gmail.com>,
Thorsten =?utf-8?q?Schütt?= <schuett at gmail.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/114784 at github.com>


paulwalker-arm wrote:

When designing the isel for SVE we had three main objectives:
1. Have patterns that select to a single instruction.  This encourages a more complete DAG for better pre-selection optimisations.
2. Try not to have multiple patterns that resolve to the same instruction, although PatFrags are allowed.  This encourages uniformity of the DAG to maximise the applicability of target specific combines and promotes reuse within the tablegen files.
3. Try to preserve information relating to which lanes are defined.  This allows us to make good use of SVE's various immediate and reversed instruction forms as well as enabling movprfx'ing for cases where the register allocation is not ideal.  We also use this so as not to introduce side effects for things like floating point operations.

Very early on it became apparent the common ISD nodes were not fit for purpose in achieving these goals.  If our use case was to only code generate stock LLVM IR then we might have gotten away with it.  However, once you factor in all the intrinsics required to implement the ACLE along with potentially supporting fixed length vector types from 2048-bit down to 128-bit you soon realise the need for a matching set of predicated ISD nodes.  This is essentially what we have implemented and whilst we might not always achieve the above objectives, on the whole we're pretty close and I certainly don't want global-isel preventing us from closing any gaps.

With that said, I'm completely ignorant when it comes to global-isel and so only offer the following guidance:
1. Make sure there's significant value in enabling global-isel for SVE before embarking on what's likely to be a long mission.
2. Functional global-isel for SVE is of no value if the code quality is not good. I don't recommend a piecemeal implementation that assumes SVE is just NEON but using scalable vector types.
3. Predication is key to efficient SVE code generation and any representation that doesn't support it is likely to be flawed.

https://github.com/llvm/llvm-project/pull/114784