Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:27
    steven-johnson synchronize #7282
  • 20:26

    steven-johnson on main

    Float16: Remove unused header d… (compare)

  • 20:26
    steven-johnson closed #7324
  • 20:26
    steven-johnson synchronize #7326
  • 20:26

    steven-johnson on _float16

    Fixes for top-of-tree LLVM (#73… Merge branch 'main' into srj/_f… (compare)

  • 20:25

    steven-johnson on triplefix

    (compare)

  • 20:25

    steven-johnson on main

    Fixes for top-of-tree LLVM (#73… (compare)

  • 20:25
    steven-johnson closed #7329
  • 20:25
    steven-johnson synchronize #7329
  • 20:25

    steven-johnson on triplefix

    Update LLVM_Output.cpp (compare)

  • 20:21
    steven-johnson commented #7329
  • 20:00
    abadams commented #7329
  • 20:00
    abadams commented #7329
  • 19:44
    steven-johnson commented #7329
  • 19:41
    steven-johnson synchronize #7329
  • 19:41

    steven-johnson on triplefix

    times ten (compare)

  • 19:23
    steven-johnson review_requested #7329
  • 19:23
    steven-johnson review_requested #7329
  • 19:23
    steven-johnson review_requested #7329
  • 19:23
    steven-johnson opened #7329
Roman Lebedev
@LebedevRI
alexreinking: like in previous occurrences, by CFLAGS i don't literally mean the env variable, i mean the argument list that would have been passed to the clang/compiler
Alex Reinking
@alexreinking:matrix.org
[m]
Okay, but what if you're using GCC's coverage implementation?
We cannot be in the business of parsing third party compiler command lines
The person controlling the build is in charge of configuring their tools. Someone set -fsanitize=fuzzer-no-link. It's their responsibility to configure Halide as necessary, too. Just like if they were going to set CXXFLAGS or FFLAGS in the same project
Since CMake is our blessed build system and we prefer our AOT users to go through our helpers, adding a configuration point there makes the most sense to me.
Roman Lebedev
@LebedevRI
let me clarify: i personally would have viewed halide as an, essentially, 'alternative' clang-based front-end. is that already off-target?
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?