[llvm-dev] AMDGPU and support for the new pass manager

Arthur Eubanks via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 19 09:31:01 PST 2021


Any update on this? This is the last known remaining NPM issue assuming
https://reviews.llvm.org/D94153 is good to go.

On Thu, Jan 14, 2021 at 10:16 AM Arthur Eubanks <aeubanks at google.com> wrote:

> Here's what I understood so far from a general eyeballing of the code:
>>
>> 1. Legacy DA is a wrapper around GPU DA. I could not find any direct use
>> of GPU DA.
>> 2. It is likely that AMDGPU no longer "requires" Legacy DA. The advantage
>> of the Legacy DA is that it can handle irreducible regions, but we usually
>> convert them into loops for AMDGPU anyway. I don't know if we have reached
>> a point where we don't care about legacy DA in this respect.
>> 3. StructurizeCFG under the new pass manager simply skips DA, and
>> consequently cannot skip uniform regions. This essentially disables an
>> optimization when moving to the new pass manager.
>> 4. Similarly, loop unswitching is an optimization and available in its
>> simple form with the new pass manager. But I don't know for sure if it
>> *must* skip loops with divergent values.
>>
>> So we (the AMDGPU folks) need to figure out how much is our dependency on
>> any DA in the new pass manager. Besides the above optimizations, isn't it
>> required for later target optimizations around SGPR usage? Is it possible
>> to unblock the transition to the new pass manager, and then later restore
>> these optimizations? Also, I am wondering if can focus on making only the
>> new GPU DA available subject to #2 above.
>>
>
> To be clear, currently the new PM switch only affects the optimization
> pipeline, which out of all the uses of Legacy DA only affects LoopUnswitch
> and StructurizeCFG. The other uses are in the codegen pipeline which isn't
> affected.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210119/4fe89403/attachment.html>


More information about the llvm-dev mailing list