Tags: gprateek93/iree
Tags
Clean old lit tests up. (iree-org#7894) Most of passes are moved before memrefs world. The LLVMCPULowerExecutableTargetPass starts with tensors world. This PR updates the tests to tensors version as input. Also delete a dup test case (@test_exp_2), which is as same as @test_exp_0.
Merge google -> main (iree-org#7884) * 6304d39 Merge pull request iree-org#7883 from hanhanW:main-to-google * 608f0c7 Merge pull request iree-org#7880 from hanhanW:disable-test * addf5db Merge pull request iree-org#7882 from hanhanW:b2c * 09f29a6 Synchronize submodules with LLVM at llvm/llvm-project@48d868493fa7 * 5883da5 Integrate LLVM at llvm/llvm-project@48d868493fa7 * b38a3fc Integrate LLVM at llvm/llvm-project@b04c64671150
Merge google -> main (iree-org#7884) * 6304d39 Merge pull request iree-org#7883 from hanhanW:main-to-google * 608f0c7 Merge pull request iree-org#7880 from hanhanW:disable-test * addf5db Merge pull request iree-org#7882 from hanhanW:b2c * 09f29a6 Synchronize submodules with LLVM at llvm/llvm-project@48d868493fa7 * 5883da5 Integrate LLVM at llvm/llvm-project@48d868493fa7 * b38a3fc Integrate LLVM at llvm/llvm-project@b04c64671150
Rework module nesting in VM conversion. (iree-org#7873) Introduces an explicit `vm.toplevel` attribute when setting up the nesting and then uses this as a signal that a nested module should be considered legal and left alone. The heuristic previously in use was to attempt to infer this based on parents. This turned out to be fragile if nesting a new module in an existing module (i.e. to extract a partial program and compile it without intending to create a layering issue). I was going to clean the attribute up at the end but opted to leave it there as it was a good debugging aid as I tried to figure out what was going on. Moved the one nesting test to a new nesting.mlir test case and reworked it to use a non-root based pipeline, which is more realistic for this scenario. Also, verified that what this test was doing was wrong (checks on "module" were inadvertently matching "vm.module", which was not the desired outcome). I believe the current tested behavior is desired.
Rework module nesting in VM conversion. (iree-org#7873) Introduces an explicit `vm.toplevel` attribute when setting up the nesting and then uses this as a signal that a nested module should be considered legal and left alone. The heuristic previously in use was to attempt to infer this based on parents. This turned out to be fragile if nesting a new module in an existing module (i.e. to extract a partial program and compile it without intending to create a layering issue). I was going to clean the attribute up at the end but opted to leave it there as it was a good debugging aid as I tried to figure out what was going on. Moved the one nesting test to a new nesting.mlir test case and reworked it to use a non-root based pipeline, which is more realistic for this scenario. Also, verified that what this test was doing was wrong (checks on "module" were inadvertently matching "vm.module", which was not the desired outcome). I believe the current tested behavior is desired.
PreviousNext