search

halide / Halide

a language for fast, portable data-parallel computation
https://halide-lang.org
Other
5.91k stars 1.07k forks source link

JITModule: rework/fix `__udivdi3` handling #8389

Open LebedevRI opened 3 months ago

LebedevRI commented 3 months ago

The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific.

Instead:

  1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still.
  2. Replace HalideJITMemoryManager hack with a more direct approach of actually telling the JIT the address of the symbol.
  3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there.

This makes python binding tests pass on i386, and i'm really happy about that.

https://ci.debian.net/packages/h/halide/testing/i386/50395069/#L2243

Refs. https://github.com/llvm/llvm-project/issues/61289 Inspired by https://github.com/root-project/root/pull/13286

LebedevRI commented 3 months ago

Ok, how about this?

LebedevRI commented 3 months ago

buildbot/halide-testbranch-main-llvm20-x86-32-linux-cmake suggests this should also be passing CFLAGS so cross-compilation of the halide itself to another arch works, i guess.

But as far as i can tell (from https://buildbot.halide-lang.org/master/#/builders/164/builds/123/steps/8/logs/stdio), that build job is achieved via

 environment:
  CC=gcc-9 -m32

Shouldn't that be 

 environment:
  CC=gcc-9
  CFLAGS=-m32
  CXXFLAGS=-m32

Otherwise i'm not really sure how that can be detected.

steven-johnson commented 6 days ago

Is this still an active PR?