Amara Emerson via llvm-dev
2020-May-01 17:12 UTC
[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://reviews.llvm.org/D79207>, 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/9f87221d/attachment.html>
Arsenault, Matthew via llvm-dev
2020-May-01 17:28 UTC
[llvm-dev] RFC: [GlobalISel] propagating int/float type information
[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 -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/d2eee265/attachment.html>
Amara Emerson via llvm-dev
2020-May-01 18:00 UTC
[llvm-dev] 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 RegBankSelectPractically 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>
Ties Stuij via llvm-dev
2020-May-05 11:19 UTC
[llvm-dev] RFC: [GlobalISel] propagating int/float type information
I don't know too much about GlobalIsel, but I'm working on adding a new bfloat IR/MVT type (16-bit float type) to LLVM, and on one of the patches Amara raised the issue what we would to to disambiguate between a half and a bfloat for GlobalIsel. Just wanted to highlight that BFloat might be another use-case for this. Cheers, /Ties ________________________________________ 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: 01 May 2020 18:12 To: LLVM Developers' List Cc: Matt Arsenault 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, 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.
Quentin Colombet via llvm-dev
2020-May-05 16:59 UTC
[llvm-dev] RFC: [GlobalISel] propagating int/float type information
I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more manageable to have the floating point type long term. That said, it also depends on what we decide to do at the IR level. For instance, if bfloat support in the IR is limited to intrinsics, we wouldn’t need to go down that road.> On May 5, 2020, at 4:19 AM, Ties Stuij via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I don't know too much about GlobalIsel, but I'm working on adding a new bfloat IR/MVT type (16-bit float type) to LLVM, and on one of the patches Amara raised the issue what we would to to disambiguate between a half and a bfloat for GlobalIsel. > > Just wanted to highlight that BFloat might be another use-case for this. > > Cheers, > /Ties > > ________________________________________ > 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: 01 May 2020 18:12 > To: LLVM Developers' List > Cc: Matt Arsenault > 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, 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. > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Seemingly Similar Threads
- RFC: [GlobalISel] propagating int/float type information
- RFC: [GlobalISel] propagating int/float type information
- RFC: [GlobalISel] propagating int/float type information
- [GlobalISel] Legalize generic instructions that also depend on type of scalar, not only scalar size
- RFC: [GlobalISel] propagating int/float type information