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

Madhur Amilkanthwar via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 6 01:07:18 PST 2024


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>


madhur13490 wrote:

> > There are no SVE patterns for fneg today. Either there is no demand for them or C++ is more efficient.
> > For GlobalISel, we have
> > 
> > * fneg pattern with implicit_def
> > * fneg pattern with movprfx
> > * C++
> > 
> > fneg is just an example. There are many predicated (merging and/or zeroing) instructions without good pattern coverage.
> > Edit: There are [s,u][max,mix] instructions but no patterns for SVE. And there is really low hanging fruit: https://github.com/llvm/llvm-project/pull/114664/files
> > #114644
> 
> Ok so before we go ahead and diverge implementations between the two, let's first understand why SelectionDAG chose to go a different route and what the trade-offs are. If we have half-baked implementations without a cohesive idea about what the overall design should be, then that's worse than not having anything at all. E.g. let's think about how to incorporate the data-dependency breaking part that Paul mentioned before.

I think we should have a RFC for this. The plan for SVE implementation should be spelled out at some point. How are we approaching this? What pieces can be reused? I understand that we have some patches in the community (including some from my team) but we should take a moment and write down at least a rough plan. 

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


More information about the llvm-commits mailing list