mirror of https://github.com/llvm/torch-mlir
333e07a74e
This op is much better behaved than the `torch.tensor.literal` op (which is the new name of the `torch.tensor` op). In particular `torch.tensor.literal`: - always has a maximally refined type. - always has value semantics. - can be constant folded / CSE'd. ReduceOpVariants is changed to perform the transformation from `torch.tensor.literal` to `torch.vtensor.literal` (which in general involves static information casts and copies. This new op also allowed tightening up `torch.tensor.literal` to only accept NonValueTensorType (instead of any tensor type). This new ".literal" name is more descriptive. It was getting too confusing seeing an op called just `torch.tensor` (we originally called it that because that's the name of the similar function in the Torch Python API, but it just doesn't fit here). |
||
|---|---|---|
| .. | ||
| pytorch | ||
| README.md | ||
| __init__.py | ||
README.md
NPComp - Frontends
NPComp maintains in-tree frontends for various popular numeric-python based frameworks. In general these are:
- Considered optional components
- Target dialects maintained at the top-level of the project
- Maintained in isolation so as to facilitate moving them out to dedicated projects at an appropriate point of the lifecycle (i.e. if NPComp is successful as a general purpose target for such frameworks, then it may make sense to contribute/build each frontend to their respective up-stream project).
Frontends try to stylistically fit into the outer project except for when it is more clear/advantageous to align them with the conventions of the source project. This is approached on a case by case basis as needed. Deviations should be documented in a local style guide for the frontend.