[llvm-dev] [GlobalISel] Legalization for memcpy family intrinsics

[Devadasan, Christudasan via llvm-dev]

Hi All,

 

I was trying to legalize the family of memcpy intrinsics (memcpy, memmove and memset) for AMDGPU and found that the combiner functions optimizeMemcpy, optimizeMemmove and optimizeMemset implemented in CombinerHelper.cpp pretty much handle these lowering.

 

Can we move these functions to Legalizer entirely and perform a custom legalization to handle their expansion?

The reason is, in the Combiner it is more of an optimization action rather than something required always for correctness.

 

On the other hand, if these combiner expansions turned out to be unavoidable, we should move these function into a common file.

In that way, both Legalizer and Combiner can take advantage of them.

 

Regards,

CD

[Amara Emerson via llvm-dev]

On Dec 16, 2020, at 6:47 AM, Devadasan, Christudasan <Christudasa...@amd.com> wrote:

Hi All,

 

I was trying to legalize the family of memcpy intrinsics (memcpy, memmove and memset) for AMDGPU and found that the combiner functions optimizeMemcpy, optimizeMemmove and optimizeMemset implemented in CombinerHelper.cpp pretty much handle these lowering.

 

Can we move these functions to Legalizer entirely and perform a custom legalization to handle their expansion?

The reason is, in the Combiner it is more of an optimization action rather than something required always for correctness.

Right, that’s how this is implemented in SelectionDAG too, it’s an optimization that may or may not fire depending on the heuristics.

 

On the other hand, if these combiner expansions turned out to be unavoidable, we should move these function into a common file.

In that way, both Legalizer and Combiner can take advantage of them.

I think refactoring it to be shared is ok, but I and others disagree that this is a legalization issue rather than a combiner. There is no question of legality here, the target should be able to handle these opcodes. If they’re not legal for your target, then you could simply not use the expansion combines and handle them using custom legalization like any other operation.

Amara

 

Regards,

CD

[Matt Arsenault via llvm-dev]

On Dec 16, 2020, at 13:52, Amara Emerson via llvm-dev <llvm...@lists.llvm.org> wrote:

On Dec 16, 2020, at 6:47 AM, Devadasan, Christudasan <Christudasa...@amd.com> wrote:

Hi All,

 

I was trying to legalize the family of memcpy intrinsics (memcpy, memmove and memset) for AMDGPU and found that the combiner functions optimizeMemcpy, optimizeMemmove and optimizeMemset implemented in CombinerHelper.cpp pretty much handle these lowering.

 

Can we move these functions to Legalizer entirely and perform a custom legalization to handle their expansion?

The reason is, in the Combiner it is more of an optimization action rather than something required always for correctness.

Right, that’s how this is implemented in SelectionDAG too, it’s an optimization that may or may not fire depending on the heuristics.

This is a largely a function of SelectionDAG not supporting the necessary loop-based expansions since you can’t introduce control flow. The current scheme is a hacky split between IR and DAG expansions.

 

On the other hand, if these combiner expansions turned out to be unavoidable, we should move these function into a common file.

In that way, both Legalizer and Combiner can take advantage of them.

I think refactoring it to be shared is ok, but I and others disagree that this is a legalization issue rather than a combiner. There is no question of legality here, the target should be able to handle these opcodes. If they’re not legal for your target, then you could simply not use the expansion combines and handle them using custom legalization like any other operation

There is a question of legality, just as with every other opcode. The legalizer should support the necessary expansion, and these shouldn’t be special.The expansion can be done context free, so I think it fundamentally isn't a combine. Splitting the expansion decisions between two places would be just as messy as the DAG

-Matt

[Devadasan, Christudasan via llvm-dev]

Can we conclude this discussion?

I believe legalizer is the right place for this expansion.

 

Regards,

CD

 

From: Matt Arsenault <whatmannerof...@gmail.com> On Behalf Of Matt Arsenault
Sent: Thursday, December 17, 2020 7:38 AM
To: Amara Emerson <am...@apple.com>
Cc: Devadasan, Christudasan <Christudasa...@amd.com>; llvm...@lists.llvm.org
Subject: Re: [llvm-dev] [GlobalISel] Legalization for memcpy family intrinsics

 

[CAUTION: External Email]

[Devadasan, Christudasan via llvm-dev]

Pinging once again after the long holiday.

 

Regards,

CD

[Devadasan, Christudasan via llvm-dev]

Hi Amara,

 

If you still have any objection against moving the expansion of these memory intrinsics entirely into legalizer, please let us know.

Much appreciate it.

 

Regards,

CD

 

From: Devadasan, Christudasan
Sent: Monday, December 21, 2020 7:40 PM
To: Matt Arsenault <ars...@gmail.com>; Amara Emerson <am...@apple.com>
Cc: llvm...@lists.llvm.org

[Amara Emerson via llvm-dev]

I still disagree but I’m not going to spend more time on this discussion. Move it over to legalization if you must.