Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Driver] Single-module lowering flow in driver_api.cc #14985

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Commits on Sep 11, 2024

  1. [Driver] Single-module lowering flow in driver_api.cc

    Prior to this commit, a build that used multiple targets needed to
    provide `tvm::build` with a `Map<Target, IRModule>` specifying which
    target should be used to compile each `IRModule`.  As a result,
    lowering passes could not introduce new targets based on a PrimFunc's
    content (e.g. a `with T.target()` frame to delegate out to another
    device), nor simplify based on cross-device subroutines (e.g. simplify
    a host-side conditional based on the known output of a device-side
    internal subroutine).
    
    This commit makes the `tvm::attr::kTarget` attribute (`"target"`) be
    the single source of truth for where a `PrimFunc` will be executed.
    Other existing methods for specifying the target (the `target`
    parameter for `tvm.build`, the keys in a `Map<Target,IRModule>`, the
    parameter to the pass `tir::transform::BindTarget`) are still accepted
    as inputs, and may provide a default value for `tvm::attr::kTarget` if
    the attribute is missing, but may not overwrite the target attribute.
    
    This is part of a series of commits to simplify the handling of
    multi-target builds.
    Lunderberg committed Sep 11, 2024
    Configuration menu
    Copy the full SHA
    ba8aaca View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    e7bebaf View commit details
    Browse the repository at this point in the history

Commits on Sep 13, 2024

  1. [TIR] Output DeclBuffer in FlattenBuffer

    If a flattened buffer is produced for use in `BufferLoad` and
    `BufferStore` statements, generate a `DeclBuffer`.
    
    This is a subset of the changes made in
    apache#14778, broken out for ease of
    testing and review.
    Lunderberg committed Sep 13, 2024
    Configuration menu
    Copy the full SHA
    05854f1 View commit details
    Browse the repository at this point in the history
  2. [TIR] Output DeclBuffer nodes during StorageFlatten

    When producing a flattened buffer for use in `BufferLoad` and
    `BufferStore` nodes, generate a `DeclBuffer` for the flattened buffer.
    
    This is a subset of the changes made in
    apache#14778, broken out for ease of
    testing and review.
    Lunderberg committed Sep 13, 2024
    Configuration menu
    Copy the full SHA
    021a2d1 View commit details
    Browse the repository at this point in the history