[AMD] Add buffer support

[giuseros]

This PR is building on top of #4638 to finally add support for buffer operations. For now we will focus on buffer load/store, but in the future we might add more. What this PR is doing:

• Adding inferred properties for non-negativeness (tt.non_negative) and the size of the memory buffers passed (tt.within_2gb)
• Adding a series of checks to be sure we can emit the buffer load instructions (non negativeness, 32bitness of the offsets, etc..)
• Change to the canonicalizer pointer pass to take into account the tt.within_2gb property
• Add a generic infra to emit masked buffer ops. For now we will use it to emit masked buffer loads and stores, but in the future we might want to add more.
• I am shielding this feature behind a AMDGCN_USE_BUFFER_OPS. In this way we can enable the feature gradually and check for possible performance/correctness issues.

[ThomasRaoux]

just putting a blocker on this as some pieces will need a bit more discussions. Lei had mentioned those to me so it's not a surprise but haven't had a chance to discuss it with Phil and the rest of the team yet

[ThomasRaoux]

Do we have some data on the performance impact of this feature? Considering the cost in extra compilations and maintenance it would be good to have this information

[ThomasRaoux]

After having a quick chat with @ptillet one problem is that the specialization will apply to all backends even the ones that can't take advantage of that.
@antiagainst @giuseros, Can you make separate changes to refactor the specialization and allow different backends to have different specializations first?

[giuseros]

Do we have some data on the performance impact of this feature? Considering the cost in extra compilations and maintenance it would be good to have this information

Yes, if we run on a non-power-of-two shape we get up to 36% improvement:

These are gfx11 numbers, but I had the same with mi200 and mi300. For power-of-two shapes the perfs are similar

[giuseros]

just putting a blocker on this as some pieces will need a bit more discussion

Absolutely fine, I put it here exactly to have discussions while we get on with #4638

[giuseros]

I rebased against recent fixes/refactors/etc... I also found out that there is a benefit also when we use it on power-of-two sizes (this is still on my gfx11 card):

This seems to be because there is a reduction in the number of registers used (we don't have to have the set of pointers around. We only need to update the scalar base pointer - unless there is a non-uniform update within the loop, which is rare)

However, for "bad" configurations (i.e., the ones not picked by the tuner) sometimes I see an increase in reg pressure (using buffer ops). So I still think this feature needs to be shielded behind an environment variable to allow further experimentation.