This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Fix build & test of mlir python bindings on Windows
ClosedPublic

Authored by stella.stamenova on May 6 2022, 12:52 PM.

Details

Summary

There are a couple of issues with the python bindings on Windows:

  • create_symlink requires special permissions on Windows - using copy_if_different instead allows the build to complete and then be usable
  • the path to the python_executable is likely to contain spaces if python is installed in Program Files. llvm's python substitution adds extra quotes in order to account for this case, but mlir's own python substitution does not
  • the location of the shared libraries is different on windows
  • if the type is not specified for numpy arrays, they appear to be treated as strings

I've implemented the smallest possible changes for each of these in the patch, but I would actually prefer a slightly more comprehensive fix for the python_executable and the shared libraries.

For the python substitution, I think it makes sense to leverage the existing %python instead of adding %PYTHON and instead add a new variable for the case when preloading is needed. This would also make it clearer which tests are which and should be skipped on platforms where the preloading won't work.

For the shared libraries, I think it would make sense to pass the correct path and extension (possibly even the names) to the python script since these are known by lit and don't have to be hardcoded in the test at all.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2022, 12:52 PM
stella.stamenova requested review of this revision.May 6 2022, 12:52 PM
mehdi_amini added inline comments.May 6 2022, 12:55 PM
mlir/test/python/dialects/shape.py
26

I didn't quite get the issue here?

mlir/test/python/dialects/shape.py
26

This was much fun (?) to investigate. The test expects the produced shape to look like:

shape.const_shape [10, 20] : tensor<2xindex>

Instead, on Windows, we get:

shape.const_shape [85899345930, 85899345930] : tensor<2xindex>

As far as I can tell, what's happening is that on Windows, unless the type is explicitly specified, the values are treated as a string when passing from the python layer to the C++ layer. Then the DenseElementsAttr on Windows is treated as splat resulting in the 85899345930 value (85899345930 is 0x140000000A; 0x14 is 20 and 0xA is 10). If the type is specified, everything works as expected. There are some other tests that also explicitly specify the type, so I opted to do so and did not investigate further.

Thanks for the fixes. I'm out today but will have a detailed look this weekend. Over time, I've tried to keep these things working for Windows but we must be building with a Windows setup that doesn't tickle the weird bits.

One request: can we special case the copy_if_different thing for Windows only. Symlinks are pretty convenient for dev because you can just edit/run, and I'd prefer to not regress that too account for this weird Windows-ism.

Thanks for the fixes. I'm out today but will have a detailed look this weekend. Over time, I've tried to keep these things working for Windows but we must be building with a Windows setup that doesn't tickle the weird bits.

One request: can we special case the copy_if_different thing for Windows only. Symlinks are pretty convenient for dev because you can just edit/run, and I'd prefer to not regress that too account for this weird Windows-ism.

I updated it to use symlinks when not on Windows. This is the smallest set of changes needed to work on Windows and once it's in, I'd like to turn on the build of the python bindings on the buildbot as well.

Thanks for the fixes. I'm out today but will have a detailed look this weekend. Over time, I've tried to keep these things working for Windows but we must be building with a Windows setup that doesn't tickle the weird bits.

One request: can we special case the copy_if_different thing for Windows only. Symlinks are pretty convenient for dev because you can just edit/run, and I'd prefer to not regress that too account for this weird Windows-ism.

I updated it to use symlinks when not on Windows. This is the smallest set of changes needed to work on Windows and once it's in, I'd like to turn on the build of the python bindings on the buildbot as well.

Thanks. I am open to more refactorings once we do that. Thank you for the help.

I'll need to check when I'm back online, but I could have sworn we had this enabled on a bot somewhere (I've broken it before). But in any case, +1 on more coverage.

I'll need to check when I'm back online, but I could have sworn we had this enabled on a bot somewhere (I've broken it before). But in any case, +1 on more coverage.

The python bindings are enabled on several different linux/ubuntu bots, but not on the windows bot (https://lab.llvm.org/buildbot/#/builders/13). I sent the change for that as well (https://reviews.llvm.org/D125134), but I'm not planning on committing it before this weekend even if I commit the change to the source because I don't want to deal with potential breaks over the weekend :).

mehdi_amini added inline comments.May 7 2022, 3:01 AM
mlir/test/python/dialects/shape.py
26

I'm concerned about fixing the test instead of fixing the infrastructure: this seems like the kind of things that will hit users.

stellaraccident accepted this revision.May 7 2022, 8:04 AM

LGTM modulo nits and open discussion

mlir/cmake/modules/AddMLIRPython.cmake
235

Cmake style isn't really a thing, but I do generally try to be consistent within a macro/file. In this case, "local" variables are named _like_this. Can we just call this _link_or_copy?

mlir/test/lit.cfg.py
97

So. Quites to quotes

mlir/test/python/dialects/shape.py
26

In this specific case, I'd be open to an issue and references to it in the code. These kind of platform specific corners are hard to get a complete lock on in one step, and I would bias towards landing this so that we get bot coverage, and then fix from there.

mlir/test/python/execution_engine.py
348

This could be made generic with sysconfig.get_config_var('SHLIB_SUFFIX') (and I think there is a corresponding prefix). I'm a little uncertain how/if this is working on macos, which is also different. Certainly, if we had three cases here, I would generalize it in some way.

I'm ok to leave as is for now since Windows is different in many details here.

This revision is now accepted and ready to land.May 7 2022, 8:04 AM
stella.stamenova marked 2 inline comments as done.May 7 2022, 12:28 PM
stella.stamenova added inline comments.
mlir/cmake/modules/AddMLIRPython.cmake
235

I updated it to match this file. I had originally followed the pattern used in llvm (addllvm.cmake, etc.). I wish there was a consistent style within llvm-project :(.

mlir/test/python/dialects/shape.py
26

My goal with these changes is to get things working enough on Windows, so we can add it to the bot. I think this won't be a simple change to fix and I already spent quite a bit of time trying to track it down.

mlir/test/python/execution_engine.py
348

We would actually need three different things: prefix, suffix and path (bin on Windows, lib most everywhere else). This would be needed for a number of the other tests that are currently disabled on Windows as well. I also noticed that some of the python tests set the environment before making the call to their respective scripts and the same could be done here. My preference would be to fix this locally in the file for the moment and then have a more comprehensive change to normalize how the shared libraries are set among all of the tests.

stellaraccident accepted this revision.May 7 2022, 2:38 PM
stellaraccident added inline comments.
mlir/test/python/dialects/shape.py
26

I agree. Can you file an issue. Feel free to assign it to me. Since the test fix is subtle, I don't have confidence that I'll remember the repro workout details.

mlir/test/python/execution_engine.py
348

Yeah. I think the prefix and suffix can come from the environment but the location is an llvm thing. Fine with me to do this as you have it. Then we can have a better look.

I can't say I love all this open coded execution engine library integration, and I've also made point fixes to it over time (but have never looked at the whole).

mehdi_amini added inline comments.May 8 2022, 3:00 AM
mlir/test/python/dialects/shape.py
26

Perfectly fine with me to track this as an issue to fix later: I just wanted to make sure we agree there is an issue to be fixed (and we track it) :)

This revision was landed with ongoing or failed builds.May 9 2022, 11:11 AM
This revision was automatically updated to reflect the committed changes.
stella.stamenova marked an inline comment as done.