[Triton][Allocation] Enable getScratchValueSize specialization

[victor-eds]

Allow passing a functor to ModuleAllocation constructor to override
getScratchValueSize in the allocation analysis. This parameter will
be a default implementation by default.

The core Triton is a small number of people, and we receive many PRs (thank
you!). To help us review your code more quickly, if you are a new
contributor (less than 3 PRs merged) we ask that you complete the following
tasks and include the filled-out checklist in your PR description.

Complete the following tasks before sending your PR, and replace [ ] with
[x] to indicate you have done them.

• I am not making a trivial change, such as fixing a typo in a comment.

• I have written a PR description following these
  rules.

• I have run pre-commit run --from-ref origin/main --to-ref HEAD.

• Select one of the following.

  • I have added tests.
    • /test for lit tests
    • /unittest for C++ tests
    • /python/test for end-to-end tests
  • This PR does not need a test because it isn't modifying compiler functionality, just enabling new memory allocation analysis implementations to be used while keeping the same interface.

• Select one of the following.

  • I have not added any lit tests.
  • The lit tests I have added follow these best practices,
    including the "tests should be minimal" section. (Usually running Python code
    and using the instructions it generates is not minimal.)

[Jokeren]

In general, the changes are fine to me, but I need to think about it a bit more later since it involves interfaces. Please remind me in a few days

[victor-eds]

In general, the changes are fine to me, but I need to think about it a bit more later since it involves interfaces. Please remind me in a few days

Thanks, @Jokeren. I'll get back to this.

[ThomasRaoux]

Is the main motivation to be able to decouple getScratchValueSize from the analysis? I'm not convince this is the right direction here and exposing more internal data structure seems unlikely to be very future proof.
Could you give more details on what you need? I think allowing backends to provide their own allocation size for ops make sense, we had discussed having an interface for that at some point, it might be a better solution

[victor-eds]

Is the main motivation to be able to decouple getScratchValueSize from the analysis? I'm not convince this is the right direction here and exposing more internal data structure seems unlikely to be very future proof. Could you give more details on what you need? I think allowing backends to provide their own allocation size for ops make sense, we had discussed having an interface for that at some point, it might be a better solution

Yeah, this is mostly the case. I think the allocation analysis is pretty robust, but not extensible. Having something like that would be pretty much enough. Maybe having that function as a plugin to the analysis as you say would be better than this.

[ThomasRaoux]

Is the main motivation to be able to decouple getScratchValueSize from the analysis? I'm not convince this is the right direction here and exposing more internal data structure seems unlikely to be very future proof. Could you give more details on what you need? I think allowing backends to provide their own allocation size for ops make sense, we had discussed having an interface for that at some point, it might be a better solution

Yeah, this is mostly the case. I think the allocation analysis is pretty robust, but not extensible. Having something like that would be pretty much enough. Maybe having that function as a plugin to the analysis as you say would be better than this.

I think adding a lambda to let the backend override the scratch size for ops is better then

[victor-eds]

I think adding a lambda to let the backend override the scratch size for ops is better then

yeah, you're right. After checking Membar I had this same idea. I'll push a new version tomorrow. Thanks for the suggestion!

[Jokeren]

LGTM, @ThomasRaoux what do you think?

[victor-eds]

LGTM, @ThomasRaoux what do you think?

Thanks for your review. @ThomasRaoux, can we get another pair of eyes on this one?