Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:49
    aekul synchronize #6856
  • Jan 27 16:52
    stevesuzuki-arm opened #7307
  • Jan 27 16:46
    stevesuzuki-arm edited #7306
  • Jan 27 15:56
    stevesuzuki-arm opened #7306
  • Jan 26 17:21

    vksnk on xtensa-codegen

    [xtensa] added code for running… (compare)

  • Jan 26 17:21
    vksnk closed #7303
  • Jan 25 21:40

    vksnk on main

    Improved halide_popcount (#7225… (compare)

  • Jan 25 21:40
    vksnk closed #7225
  • Jan 25 17:19
    alexreinking commented #7286
  • Jan 25 17:17
    steven-johnson commented #7294
  • Jan 25 17:16
    steven-johnson commented #7225
  • Jan 25 17:16
    steven-johnson commented #7282
  • Jan 25 17:16
    steven-johnson commented #7285
  • Jan 25 17:16
    steven-johnson commented #7286
  • Jan 25 10:43
    Aelphy synchronize #7303
  • Jan 25 05:54
    alexreinking synchronize #7300
  • Jan 25 05:54

    alexreinking on deps-cleanup

    Shrink diff, packaging fixes. (compare)

  • Jan 25 00:58

    vksnk on xtensa-codegen

    [xtensa] Minor DMA improvements… (compare)

  • Jan 25 00:58
    vksnk closed #7304
  • Jan 25 00:33
    vksnk review_requested #7304
Alex Reinking
@alexreinking:matrix.org
[m]
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?
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.