Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:51
    dkurt commented #7073
  • 10:01
    dkurt commented #5758
  • 09:43
    stevesuzuki-arm opened #7321
  • 08:39
    dkurt commented #5877
  • 07:56
    wuhongsheng opened #7320
  • 06:56
    aekul synchronize #6856
  • Feb 04 21:49
    MaskRay edited #7319
  • Feb 04 21:44
    MaskRay opened #7319
  • Feb 03 23:30
    derek-gerstmann synchronize #6924
  • Feb 03 23:30

    derek-gerstmann on vulkan-phase2-runtime

    Fix logic for locating entry po… Remove accidentally uncommented… Cleanup debug output for buffer… (compare)

  • Feb 03 21:18

    steven-johnson on xtensa-codegen

    Make Callable::call_argv_fast p… Make visit_leaf() public in han… Merge branch 'main' into xtensa… (compare)

  • Feb 03 21:17

    steven-johnson on main

    Make visit_leaf() public in han… (compare)

  • Feb 03 21:17
    steven-johnson closed #7318
  • Feb 03 19:55
    steven-johnson synchronize #7318
  • Feb 03 19:55

    steven-johnson on hannk

    Update ops.h (compare)

  • Feb 03 19:49
    steven-johnson review_requested #7318
  • Feb 03 19:49
    steven-johnson review_requested #7318
  • Feb 03 19:49
    steven-johnson opened #7318
  • Feb 03 19:44

    steven-johnson on hannk

    Make visit_leaf() public in han… (compare)

  • Feb 02 19:53
    abadams commented #7317
Alex Reinking
@alexreinking:matrix.org
[m]
Yes, I think so. We are not clang based, we are LLVM based. If you want, you can build Halide and your generator executables on Windows, using MSVC, and produce binaries for Linux that are compatible with the toolchains there.
Roman Lebedev
@LebedevRI
hm wait, don't you at least use clang to get the initial AST?
Alex Reinking
@alexreinking:matrix.org
[m]
Nope
Roman Lebedev
@LebedevRI
aha
Alex Reinking
@alexreinking:matrix.org
[m]
We use any C++ compiler and package the compiler as a library into the resulting application. LLVM is linked in,, too.. You run that program, which produces an AST at execution time, which is passed either to MCJIT or to the usual LLVM pipeline to produce (essentially) an object file and header pair
This is to say that we are staged in C++ rather than being a subset of C++
Roman Lebedev
@LebedevRI
i see, thank you for pointing that out. somehow i missed that. can't say i like that, but it at least explains why things are the way they are
Alex Reinking
@alexreinking:matrix.org
[m]
Having the full power of C++ to metaprogram Halide and being able to piggyback off its tooling are major boons to Halide
Roman Lebedev
@LebedevRI
hm, also, no -mcpu=native?
Alex Reinking
@alexreinking:matrix.org
[m]
Target host
Roman Lebedev
@LebedevRI
that's cpu feature (isa set) detection, i'm talking about actual instruction scheduling
(but maybe i just didn't find it yet)
Alex Reinking
@alexreinking:matrix.org
[m]
Ah, not sure about that.
Roman Lebedev
@LebedevRI
are halide abi/api stability guarantees documented somewhere?
Alex Reinking
@alexreinking:matrix.org
[m]
We use semver.
So we maintain ABI stability within a major version, only add APIs within minor versions, and change neither within patch versions
The master branch has no guarantees at all
And we branch off of master to release new major versions.
Zalman Stern
@zvookin
We’ve talked about adding pass through of fine grained LLVM parameters, such as one would want for choosing the microarchitecture to target. No such feature exists right now.
If we do it as a string pass through, it’s pretty easy to implement. Part if the idea of Target was to provide a better API to configuring the backend. So commonly used things may still get surfaced there, but there is no way we’re going to put all of LLVM’s flags in Target.
There is also the issue of being able to pass in string arguments that conflict with something Halide is passing to LLVM via e.g. mcpu or mattrs.
Zalman Stern
@zvookin
E.g. some of the codegen classes make an arbitrary choice of microarchitecture to pass to LLVM. Thus it might be useful for the API Target provides to specify that should be turned off.
Hopefully this helps but the tl;dr is the feature doesn’t exist yet but we should add it.
Where “we” means anyone is welcome to take a crack at doing so :-)
Alex Reinking
@alexreinking:matrix.org
[m]
Worth discussing at our post holiday dev meeting
Zalman Stern
@zvookin
Oh, there is an environment variable to pass arbitrary args to LLVM at init time.
Can be used as a hack, but not good for anything production.
Roman Lebedev
@LebedevRI
i think generic passthrough is a different problem from passing mcpu
Zalman Stern
@zvookin
Yes, probably. But pass through in the sense that it is a string that Halide doesn’t parse
Roman Lebedev
@LebedevRI
i'm just trying to understand if i should follow the pattern and submit a tiny patch to add avx2_znver3 feature, or look directly into string-based mcpu support
Zalman Stern
@zvookin
Adding an mcpu thing to Target is likely pretty simple and maybe a good idea without solving attributes
If it is a change in the instruction set, it probably needs a feature flag.
There’s another wrinkle…
Roman Lebedev
@LebedevRI
is it though? there already is a avx2 feature
Zalman Stern
@zvookin
Features are also used to choose between multiple separately compiled implementations at runtime
I don’t know if znver3 is a change in the ISA or just performance
Roman Lebedev
@LebedevRI
this actually highlights bigger upcoming issue: suppose mcpu string is implemented. now you have two ways to encode isa/cpu - mcpu string and features
Zalman Stern
@zvookin
But the automatic choosing of differently compiled code based on feature flags can also be used for just performance things.
And the automatic choice implementation depends on it being a bit set.
I think features should drive a default choice of mcpu. If one wants a different choice, it is required that it be compatible with the features.
Changes in the instruction set itself — like new opcodes etc., probably should be features
We could add a utility library that constructs the right features from some input such as the name for the processor or a serialized form of its CPUID stuff or some string obtained from /proc etc.
Roman Lebedev
@LebedevRI
are llvm::sys::getHostCPUName() & friends too NIH?
Zalman Stern
@zvookin
Too NIH for what?
Roman Lebedev
@LebedevRI
i'm trying to understand why calculate_host_target() does what it does, when there's already llvm infra for that
Zalman Stern
@zvookin
Not sure we ever looked at them.
Using LLVM’s means of specifying this stuff as our means if doing it is a huge nonstarter for a variety of reasons.
Some of that has to run at runtime and cannot require LLVM. In general, Halide is not supposed to require LLVM unless one is using an LLVM based backend. That doesn’t quite work yet, but there is some work going toward it.
Zalman Stern
@zvookin
The main use case is targeting shader languages, but at some point there will be JIT backends that don’t use LLVM
Simply because LLVM is not the right tool for all jobs.