llvm dev - May 2020 - RFC: [GlobalISel] propagating int/float type information

> On May 1, 2020, at 10:28 AM, Arsenault, Matthew <Matthew.Arsenault at
amd.com> wrote:
> 
> [AMD Public Use]
> 
> 
> It seems to me like you're looking for a workaround for the fact that
nobody has put any serious optimization effort into RegBankSelect
Practically speaking, we have a compile time budget, and spending that on
reconstructing information which we willingly dropped doesn’t make sense when
the solution can be cheap. I don’t propose that we force the type distinction
back, just to allow RBS to make *fast*, reasonably optimal decisions in most
cases. If we then want to spend the rest of that CT budget in making even better
decisions, then great.

The other thing we could do is to assign speculative regbanks to vregs during
translation (if the target wants to opt-in), and then RBS can finalize the
regbanks, changing some if it deems it
necessary/optimal.
> 
> -Matt
> 
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org>
> Sent: Friday, May 1, 2020 10:12 AM
> To: LLVM Developers' List <llvm-dev at lists.llvm.org>
> Cc: Matt Arsenault <arsenm2 at gmail.com>
> Subject: [llvm-dev] RFC: [GlobalISel] propagating int/float type
information
>  
> 
> Hi,
> 
> GlobalISel currently drops all type information relating to the integer/FP
distinction during the IR translation pass, as the LLT types only represent
whether a value is a scalar/vector/pointer and it’s size/shape. To compensate,
later passes use the FP operations on those values to guess what kind of value
is being stored within that virtual register.
> 
> This means that i32/float loads get translated into the same thing, and
only when that value is used, say by an fadd, then will we know that it was an
FP value. The regbankselect pass on AArch64 currently tries to walk uses/defs in
order to guess what kind fo regbank to assign to vregs. This however doesn’t
work all the time, and most commonly, it doesn’t work when a load of an FP value
is used in a loop. In that case, the FP users are obscured by PHIs which make it
difficult (although not strictly impossible) to guess what regbank to assign.
This has drastic consequences for performance on FP workloads.
> 
> But this isn’t the first time we’ve had this kind of issue, and it probably
won’t be the last [1].  propose that we have some form of type hint propagation
done at the IRTranslator stage in order to make this whole situation easier (and
faster in compile-time).
> 
> Option 1) We use some form of metadata on the MIR instructions like G_LOADs
to signify that the vreg defined likely has an FP IR type. IIUC the current
Metadata MachineOperand type is only intended for debug info. This approach is
probably the cheapest in compile time/complexity and is the least invasive, but
we’d need to find somewhere in MachineInstr to store this extra information.
> 
> Option 2) Store the type hints in an analysis. In its simplest form at
translation time we could keep a set of all the vregs that we know have FP types
and then try to maintain that as new vregs are created to replace those
throughout the pipeline. Keeping it updated might turn out to be expensive
during passes like the legalizer.
> 
> Any thoughts?
> 
> Cheers,
> Amara
> 
> [1] Currently we have a workaround for the specific case in
https://reviews.llvm.org/D79207
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD79207&data=02%7C01%7CMatthew.Arsenault%40amd.com%7C2ad8d10f31314ec0cca608d7edf2ef8b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637239499966565955&sdata=FeKiUzl%2BU6p585rRqyNsens54xdYk8rd43JuZ8mf7Oo%3D&reserved=0>,
but as Matt correctly points out, this isn’t viable in the long term because
using the IR value type from the MachineMemOperand won’t work when opaque
pointers finally land.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200501/4db65880/attachment.html>

> On May 1, 2020, at 14:00, Amara Emerson <aemerson at apple.com>
wrote:
> 
> The other thing we could do is to assign speculative regbanks to vregs
during translation (if the target wants to opt-in), and then RBS can finalize
the regbanks, changing some if it deems it necessary/optimal.
This seems reasonable to me. It wouldn’t require any new infrastructure

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200504/dc8104e9/attachment.html>

> On May 4, 2020, at 2:01 PM, Matt Arsenault via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> On May 1, 2020, at 14:00, Amara Emerson <aemerson at apple.com
<mailto:aemerson at apple.com>> wrote:
>> 
>> The other thing we could do is to assign speculative regbanks to vregs
during translation (if the target wants to opt-in), and then RBS can finalize
the regbanks, changing some if it deems it necessary/optimal.
> 
> This seems reasonable to me. It wouldn’t require any new infrastructure
How would that work with illegal operations?

Would the legalizer have to preserve them?

Ditto with combines.

What I am saying is although this does not require any new infrastructure, this
is not free adopt.

Cheers,
-Quentin
> 
> -Matt
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200504/e922cafc/attachment.html>