Skip to content

Conversation

@slyubomirsky
Copy link
Contributor

Implements proposal #14899 for TIR. Adapted from Unity PR #15171, by the same method as PR #15140. Namely, a TIR PrimFunc can be specified to be private (without a global symbol attribute) in TVMScript in the prim_func decorator. By default, PrimFuncs are not private, so they will have a global_symbol attribute that is mapped to their name.

Example usage:

# not private: its global symbol will be "func"
@T.prim_func
def func(...): ...

# no global symbol included
@T.prim_func(private=True)
def func(...): ...

This did require changing very, very many tests, unfortunately.

@tvm-bot
Copy link
Collaborator

tvm-bot commented Jul 3, 2023

Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.

Generated by tvm-bot

@slyubomirsky
Copy link
Contributor Author

@junrushao Any insight on the test failures involving check_sketches (e.g., in tests/python/unittest/test_meta_schedule_schedule_rule_cross_thread_reduction.py)? Getting rid of the global symbols in those tests didn't affect them, so I'm not sure where my changes could affect these

@slyubomirsky slyubomirsky force-pushed the privacy-annotation-tir-mainline branch from 487615b to 72a542e Compare July 14, 2023 19:02
@slyubomirsky
Copy link
Contributor Author

The test errors turned out to global symbols not matching within the meta scheduler (thanks @vinx13 for the help). Hopefully will be solved shortly.

@slyubomirsky
Copy link
Contributor Author

@tqchen @vinx13 @junrushao Now that the tests pass, I would appreciate close review, as there were very many tests changed and there seemed to be a lot of functionality affected by global symbols.

LOG(FATAL) << "Do not support function type " << func->GetTypeKey();
});

TVM_REGISTER_GLOBAL("ir.BaseFuncWithoutAttr")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Looks like we always forgot to upstream this piece from the unity branch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah lol

@slyubomirsky slyubomirsky force-pushed the privacy-annotation-tir-mainline branch from acfb358 to 645d356 Compare July 19, 2023 02:06
@slyubomirsky
Copy link
Contributor Author

@tvm-bot rerun

Copy link
Member

@junrushao junrushao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is extremely meaningful contribution to overall clarity and formalization of TIR! LGTM

@junrushao junrushao merged commit 7e830e5 into apache:main Jul 20, 2023
MasterJH5574 added a commit to mlc-ai/relax that referenced this pull request Aug 1, 2023
tqchen pushed a commit that referenced this pull request Aug 1, 2023
Fix FuseOps to adapt #15137
Fix TIR TVMScript to adapt #15214
Lunderberg added a commit to Lunderberg/tvm that referenced this pull request Aug 3, 2023
Required for internal functions after PR apache#15214
csullivan pushed a commit that referenced this pull request Aug 8, 2023
Analogous to #14901, treat GlobalVar callees as internal function calls in CodeGenC. This specific PR doesn't provide new end-to-end functionality, as the target="c" backend isn't compiled. It does lead into allowing subroutines in any target whose codegen derives from CodeGenC, which will depend on the single-module lowering flow in #14985.

* [CodeGenC] Added unit tests for desired behavior

* [CodeGenC] Handle GlobalVar callee as internal function call

* Update CodeGenC subclasses for updated interface

- Call `DeclareFunction` for each `PrimFunc`, prior to any
  `AddFunction` calls

- Provide both `GlobalVar` and `PrimFunc` to `AddFunction` calls.

* Updated CRT test to expect forward declaration

* Provide forward declarations for call_extern in cmsis

* Avoid duplicate forward declaration

C's automatic pointer cast (e.g. `void*` to `int*`) means that use of
the arguments to infer the function signature may be incorrect.  If a
`call_extern` refers to a function within the same module, only output
a single forward declaration based on the PrimFunc's parameters, not
based on the CallNode's arguments.

* Updated expected ptx cuda

* Cast the AOT pools to the arg type

* Improved tvm::GetType for tvm_access_ptr and address_of

These `Call` instances can return a
`PointerType(PrimType(pointee_dtype))` rather than a
`PrimType(DataType::Handle())`.

* [ARM][Topi] Update micro kernels to use same argument type as caller

Previously, the micro kernels for gemm, avg_pool, max_pool, and
tensordot relied on C's implicit type conversions for the arguments,
when the caller's argument types differ from the signature's parameter
types.  This works, except when the codegen has auto-generated a
forward declaration based on the caller's argument types, such as
during AOT, which then causes a conflicting definition.

Since the codegen cannot determine the functions names from the
`"pragma_import_c"` in order to suppress these forward declarations,
this conflict can be more easily resolved by updating the micro kernel
signatures.  The three types of mismatches are below.

- Use of `int` or `long` parameters, whose width may vary by compiler,
  instead of fixed-width types.

- TIR expecting the data array's integer type to also be used as an
  error code's return type, rather than the micro kernels' `int32_t`
  error code.

- Pointer conversion done during argument conversion.

Type conversions are done at the start of each micro kernel, to avoid
changing types that are used within the computational sections of each
micro kernel.

* Updated unit tests with private=True

Required for internal functions after PR #15214

* Docstring updates from review
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants