[TIR] Allow multiple element offsets in Buffer

[Lunderberg]

Follow-up from #9727. When using Stage.tensorize, the element offset of the array view has one offset for each physical dimension of the buffer. This change replaces BufferNode::elem_offset and BufferNode::offset_factor with arrays. The commits in this PR are separated by category, to help in review.

Updates to Buffer class, to handle multiple elem_offsets

• Includes size checks to ensure that each parameter that depends on the number of physical dimensions (elem_offsets, offset_factors, and axis_separators) are consistent.

• Support previous Buffer constructor with a single elem_offset and offset_factor, delegating to the array-based constructor.

Update python calls, with backwards compatibility

• Buffer.elem_offset and Buffer.offset_factor are implemented as properties, to avoid breakage of calling code.

• decl_buffer handles single or multiple elem_offset and offset_factor parameters. The parameter name is unchanged, to avoid breaking call sites that use named arguments.

Updated TVMScript parser and printer

Other C++ changes

• Several other locations that referenced either elem_offsets or offset_factors, which required only minor updates to maintain existing behavior.

[tqchen]

Thanks @Lunderberg.

The multiple elem_offset is something that ideally we would like to have a deeper thoughts/discussions about. It should be a part of BufferAccess(or addition to) semantics clarification that you and @vinx13 are working on.

Moving from a single elem_offset to multiple is likely a big change and would also need some systematic thinking through the buffer access semantics.

It would also be good to think about alternatives. In TensorIR there is a subregion_match primitive to create a subregion view, and depending on the lower-level translation we may not need a buffer with multiple elem_offset explicitly.

[Lunderberg]

Thank you, and I agree that this type of change requires a larger discussion. My intent was for this draft PR to be an option in that discussion, not a ready-to-merge change on its own, and I should have edited the commit messages to make that intention clearer.

@vinx13 and I also had a brief chat on alternatives, and elem_offset may be avoidable altogether. I think the current use cases could be replaced with match_buffer/buffer_bind_scope, depending on whether a schedule is implemented in Schedulable TIR or in TE, along with using buffer.data of the subregion.

[tqchen]

Thank you @Lunderberg ! yes love all the discussions so far

[Lunderberg]

Closing this PR, unlikely to take this development path. Current behavior in which elem_offset is valid only for flat memory spaces has been working well.