similar to: [RFC] Intel AMX programming model

From: Hal Finkel <hfinkel at anl.gov> Sent: Friday, August 14, 2020 11:27 PM To: Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Kaylor, Andrew <andrew.kaylor at intel.com>; Topper, Craig <craig.topper at intel.com>; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: Re: [llvm-dev] Intel AMX programming model discussion. On

Hi Yuanke, As I said on the review, I think at least Craig should have a look and approve before landing, as this is a major change in the x86 back-end. cheers, --renato On Thu, 19 Nov 2020 at 02:29, Luo, Yuanke via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > Several months ago, we have some discussion for Intel AMX programming > model in llvm-dev. H.J.

Hi Philip, Your idea make sense to me in my first thought. Thank you for the idea. I will take more time to think it over to see it can help to reduce the complexity of tile register allocation. Yuanke From: Philip Reames <listmail at philipreames.com> Sent: Saturday, August 15, 2020 11:29 AM To: Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; florian_hahn at

Fix typo From: Luo, Yuanke Sent: Friday, September 4, 2020 9:47 PM To: 'Hal Finkel' <hfinkel at anl.gov>; Topper, Craig <craig.topper at intel.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org; florian_hahn at apple.com; Lu, Hongjiu <hongjiu.lu at intel.com> Subject: RE: [llvm-dev]

[Yuanke] AMX register is special. It needs to be configured before use and the config instruction is expensive. To avoid unnecessary tile configure, we collect the tile shape information as much as possible and combine them into one ldtilecfg instruction. The ldtilecfg instruction should dominate any AMX instruction that access tile register. On the other side, the ldtilecfg should post-dominated

On 8/20/20 2:47 PM, Topper, Craig wrote: > > I think I’m still missing something here. The configuration is per > tile. The multiply instructions take a MxK tile and multiply it by a > KxN tile and accumulate into an MxN tile. So the configuration needs > to know how many of each size of tile it needs to avoid a spill. > Wouldn’t the register allocator then need to know which

The AMX registers are complicated. The single configuration register (which is mostly used implicitly, similar to MXCSR for floating point) controls the shape of all the tile registers, and if you change the tile configuration every single tile register is cleared. In practice, if we have to change the the configuration while any of the tile registers are live, performance is going to be terrible.

Hi Hal, The proposal is attractive to me, but there is something I still can't figure out. Let's take below MIR as an example. We assume we have 256 register classes (vtile1x1, vtile1x2, ..., tile16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as

Hi Hal, There is 3 aspect to be solved. 1. The HW support max shape 16x16, so there are many register classes from 1x1 to 16x16. We need 256 register classes. 2. We want to support variable shape, so compiler don't know what register class to fit tile shape as it is only known in runtime. 3. The tile configure is to configure physical tile register, so we need to allocate

> When the tile shape is unknown at compile time, how do you plan to do the register allocation of the tiles? My question is: do you do the allocation for this case in the same way as you would if you knew the size was 16x16 (i.e., conservatively assume the largest size)? I think what will happen is that the registers are allocated based on a number of runtime values that are assumed to be

There is no problem to have 256 register classes. Just a lot of register classes to me. We don't assume the shape of each physical register be 16x16, it is defined by user. For variable shape, I mean the shape is known in runtime and in compile time the shape is unknown. Take below code as an example, the %row and %col are variable instead of constant. Compiler recognizes llvm.x86.tileloadd64

The width and height can be runtime values that we would just copy into 64 byte configuration block we pass to ldtilecfg. So the code doesn't need to be multiversioned. The user code would also use those values to update pointers in the loops they write using the tiles. If we can't determine that two tiles were defined with the same width and height we need to assume the shape is different

Hi, Yuanke, Thanks for writing this up. Let me back up a bit because the scheme I proposed last week doesn't work without further modification: within a particular "configuration region" (i.e., the code in between the LDTILECFG and the TILERELEASE (or next LDTILECFG)), each tile register can only be used with one shape, and in addition, no register can have its shape changed

On 9/4/20 3:37 AM, Luo, Yuanke wrote: > > Hi Hal, > > Thank you for the ideas that help us to improve the design, and sorry > for replying late. There is something I am not able to figure out and > there some special trait for tile RA. > You're quite welcome. > 1.X86RegisterInfo::getRegAllocationHints can tell RA which physical > register is preferred, but it

Hi, Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image, and accelerators able to operate on tiles. Capability of Intel AMX implementation is enumerated by palettes. Two palettes are supported: palette 0 represents the initialized state and

We're a dealer in Europe selling commercial phone & building management systems, some residential too. All the new office buildings have an EIB bus to manage the lights, clima, security access, etc. The big companies also have Crestron or AMX automation and media servers for the boardroom. Asterisk is an awesome phone solution, but if we could offer a solution that tied it all together

I agree we shouldn’t try to guess what the user is trying to do. There shouldn’t be an unbounded set of heuristic rules; “documented” implies some sort of promise of stability in addition to the actual text in the manual. And we shouldn’t try to guess whether the user’s code cares about the length of a specific instruction. I think you’re creating a false dichotomy here, though. There’s some

FWIW I'm with Eli here if you need any more data points. -eric On Tue, Mar 24, 2020 at 8:21 PM Eli Friedman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Changing the length of a sequence of assembly instructions will break > someone’s code at some point. The length of a sequence of instructions is > known, in general, and people will write code to take advantage of

At 6:31 AM -0700 on 8/4/05, peter webier wrote: >We're a dealer in Europe selling commercial phone & >building management systems, some residential too. >All the new office buildings have an EIB bus to manage >the lights, clima, security access, etc. The big >companies also have Crestron or AMX automation and >media servers for the boardroom. Asterisk is an >awesome

Hi Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, >