* `-mtune=`/`-mcpu=` support for x86 AMD CPU's

* Move processor tune into it's own enum, out of features

* clang-format

* Target: make Processor more optional

* Processor: add explanatory comments which CPU is what

* Drop outdated changes

* Make comments in Processor more readable / fix BtVer2 comment

* Target: don't require passing Processor

* Make processor more optional in the features string serialization/verification

* Address review notes

* Undo introduction of halide_target_processor_t

* Fix year for btver2/jaguar

* Scalarize predicated Loads

* Cleanup

* Fix gpu_vectorize scalarization for D3D12

* Fix OpenCL scalarization

* Minor fixes

* Formatting

* Address review comments

* Move Shuffle impl to CodeGen_GPU_C class

* Extra space removal

Co-authored-by: Shoaib Kamil <kamil@adobe.com>

For vector-of-Buffers, the ctor took a non-const ref to the argument, which was weird and nonsensical. Replaced with a const-ref version and and an rvalue-ref version; it turns out that literally *all* of the internal calls were able to use the latter, trivially saving some copies.

* `-mtune=native` CPU autodetection for AMD Zen 3 CPU

* Address review notes.

* Fix MSVC build

* Address review notes

* Bump development Halide version to 15.0.0

* trigger buildbots

* Remove the nobuild/partialbuildmethod tests from python_bindings/

They no longer serve a purpose and are redundant to other tests.

* WIP

* Update pystub.py

* wip

* wip

* wip

* Update TargetExportScript.cmake

* Update PythonExtensionHelpers.cmake

* PyExtensionGen didn't handle zero-dimensional buffers

…alide#6679)

* Fix "set but not used" warnings/errors

Apparently XCode 13.3 has smarter warnings about unused code and emits warnings/errors for these, so let's clean them up.

* Also fix missing `ssize_t` usage

It was deprecated (in favor of `OutputFileType` in Halide 14; let's remove it entirely for Halide 15.

This was deprecated in Halide 14; let's remove it entirely for Halide 15.

* Drop support for LLVM12

Halide 15 only needs to support LLVM13 and LLVM13. Drop all the special-casing for LLVM12.

* Update packaging.yml

* Update presubmit.yml

* 13

* more

* Update presubmit.yml

* woo

* Update presubmit.yml

* Update run-clang-tidy.sh

* Update run-clang-tidy.sh

* Update .clang-tidy

* Update .clang-tidy

* wer

* Update Random.cpp

* wer

* sdf

* sdf

* Update packaging.yml

Goal here: eliminate the need for a local version of llvm/clang-12, and don't stay too far behind the toolchain.

As always, clang-format doesn't promise backwards compatibility, but the main differences in formatting are:
- more regularization of spaces at the start of comments (I like this change)
- minor difference of formatting of function-pointer-type declarations (not a fan of this, but I can't find a way to disable it and it's only really used in a handful of place in the Python bindings)

* Always mark _ucon as 'unused' in Codegen_C, even if asserts are enabled, since generated closure functions may not use it

* halide_unused -> halide_maybe_unused

* fix test_internal

* More halide_unused -> halide_maybe_unused

…e#6694)

Clang 13 removed the `return-std-move-in-c++11` warning entirely, so specifying it now warns that the warning is unknown.

…2) (halide#6677)

* add widening_mul using vpmaddwd for AVX2

* add vpmaddwd/pmaddwd test

* add widening_mul with pmaddwd for SSE2

* Drop support for Matlab extensions

Anecdotally, this hasn't been used in ~years, and the original author (@dsharletg) had suggested dropping it a while back. I'm going to propose we go ahead and drop it for Halide 15 and see who complains.

* Fixes for top-of-tree LLVM

* Update force_include_types.cpp

* trigger buildbots

* Update CodeGen_LLVM.cpp

* llvm no longer wants a type suffix on vst intrinsics

* Fix silly mistake

* Change 64-bit only

Co-authored-by: Andrew Adams <anadams@adobe.com>

…de#6704)

This allows for `compute_with` and `rfactor` to work more seamlessly in Python.

Also:
- Move two compute_with() variant bindings from PyFunc and PyStage to PyScheduleMethods, as they are identical between the two
- drive-by removal of redundant `py::implicitly_convertible<ImageParam, Func>();` call

* Remove the last remaining call to getPointerElementType()

LLVM is moving to opaque pointers, we must have missed this one in previous work

* ARM vst mangling needs to be conditional on opaque ptrs

The fixes from last week regarding mangling of arm vst intrinsics needs to be made conditional on whether the pointer is opaque or not; this will change based on whether `-D CLANG_ENABLE_OPAQUE_POINTERS=ON|OFF` is defined when LLVM is built, but should be sniffed via this API, according to my LLVM contact.

* Revert "ARM vst mangling needs to be conditional on opaque ptrs"

This reverts commit 9901314.

The fixes from last week regarding mangling of arm vst intrinsics needs to be made conditional on whether the pointer is opaque or not; this will change based on whether `-D CLANG_ENABLE_OPAQUE_POINTERS=ON|OFF` is defined when LLVM is built, but should be sniffed via this API, according to my LLVM contact.

* Combine string constants in combine_strings()

This is a pretty trivial optimization, but when printing (or enabling `debug`), it cuts the number of `halide_string_to_string()` calls we generate by ~half.

* Update IROperator.cpp

* Update CodeGen_PTX_Dev to use new PassManager

This was still using the LegacyPassManager for optimization, which will be going away at some point. (Code changes by @alinas; I'm just opening this PR on her behalf)

* Fixes after review

…halide#6720)

Minor optimization.

…de#6719)

* Smarten type_of<> for fn ptrs; fix async_parallel for C backend

(Fixes halide#2093)

This basically just adds the right type annotations to make the parallel code produced by the C backend compile properly. This could have been fixed by inserted some brute-force void* casting into the C backend, but this felt a lot cleaner.

The one thing here I'm a little unsure about is how I extended the Type code to be able to handle function-pointer types correctly; it works but doesn't feel very elegant.

* Update Makefile

* Update LowerParallelTasks.cpp

* FunctionTypedef

)

LLVM devs indicate that none of the passes in this usage actually do anything and it can be safely removed.

…AMD CPU's (halide#6711)

I have *not* personally tested that these are detected correctly,

Cross-reference between
* https://github.com/llvm/llvm-project/blob/955cff803e081640e149fed0742f57ae1b84db7d/llvm/lib/Support/Host.cpp#L968-L1041
* https://github.com/llvm/llvm-project/blob/955cff803e081640e149fed0742f57ae1b84db7d/compiler-rt/lib/builtins/cpu_model.c#L520-L586
* https://github.com/gcc-mirror/gcc/blob/000c1b89d259fadb466e1f2e63c79da45fd17372/gcc/common/config/i386/cpuinfo.h#L111-L264

* Add Func::output_type() method

* Add Python

* Deprecate variadic-template version of Realization ctor

The variadic-template approach was useful before C++11 (!) added brace initialization, but preferring an explicit vector-of-Buffer is arguably better, and provides better symmetry with the Python bindings.

Also, some drive-by tweaks to other Realization methods.

* Update PyPipeline.cpp

* trigger buildbots

…halide#6723)

* remove arm (s | u)rhsub instructions

* remove rounding_halving_sub intrinsic entirely

halide#6734)

This enhances Func by allowing you to (optionally) constrain the type(s) of Exprs that the Func can contain, and/or the dimensionality of the Func. (Attempting to violate either of these will assert-fail.)

There are a few goals here:
- Enhanced code readability; in cases where a Func's values may not be obvious from the code flow, this can allow an in-code way of declaring it (rather than via comments)
- Enhanced type enforcement; specifying constraints allows us to fail in type-mismatched compilations somewhat sooner, with somewhat better error messages.
- Better symmetry for AOT/JIT code generation with ImageParam, in which the inputs (ImageParam) have a way to specify the required concrete type, but the outputs (Funcs) don't.

If this is accepted, then subsequent changes will likely add uses where it makes sense (e.g., the Func associated with an ImageParam should always have both type and dimensionality specified since it will always be well-known).

Note that this doesn't add any C++ template class for static declarations (e.g. `FuncT<float, 2>` -> `Func(Float(32), 2)`); these could be added later if desired.

- Allow Func output_type(s)(), outputs(), dimensions(), and output_buffer(s)() to be called on undefined Funcs if the Func has required_type and required_dimensions specified. This allows for greater flexibility in defining pipelines in which you may want to set or examine constraints on a Func that hasn't been defined yet; previously this required restructuring code or other awkwardness.
- Ensure that the Funcs that are defined for ImageParams and Generator fields define the types-and-dims when known.
- Add some tests.

* Add missing #include <function> in ThreadPool.h

* Update ThreadPool.h

That change inadvertently required the RHS of an update stage that used `+=` (or similar operators) to match the LHS type, which should be required (implicit casting of the RHS is expected). Restructured to remove this, but still ensure that auto-injection of a pure definition matches the required types (if any), and updated tests.

…ide#6741)

…lide#6740)

This is a rethink of halide#6661, trying to make it saner in anticipation of the ongoing Python Generator work.

TL;DR: instead of mixing GeneratorParams in with the rest of the keywords, segregate them into an optional `generator_params` keyword argument, which is a plain Python dict. This neatly solves a couple of problems:
- synthetic params with funky names aren't a problem anymore.
- error reporting is simpler because before an unknown keyword could have been intended to be a GP or an Input.
- GP values are now clear and distinct from Inputs, which is IMHO a good thing.

This is technically a breaking change, but I doubt anyone will notice; this is mainly here to get a sane convention in place for use with Python Generators as well.

Also, a drive-by change to Func::output_types() to fix the assertion error message.

…lide#6747)

In at least one version of GCC (Debian 11.2.0-16+build1), an optimized build using `Buffer::for_each_element(int *pos)` will give (incorrect) compiler warnings/errors that "pos may be used uninitialized).

From inspection of the code I feel pretty sure this is a false positive -- i.e., the optimizer is confused -- and since no other compiler we've encountered issues a similar warning (nor do we see actual misbehavior), I'm inclined not to worry -- but the warning does break some build configurations.

Rather than try to fight with selectively disabling this warning, I'm going to propose inserting a memset() here to reassure the compiler that the memory really is initialized; while it's unnnecessary, it's likely to be insignificant compared to the cost of usual calls to for_each_element().

(BTW, this is not a new issue, I've seen it for quite a while as this GCC is the default on one of my Linux machines... it just finally annoyed me enough to want to make it shut up.)

The current one is being sunsetted

* Add a `HalideError` base class to Python bindings

Per suggestion from @alexreinking, this remaps all exceptions thrown by the Halide Python bindings to be `halide.HalideError` (or a subclass thereof), rather than plain old `RuntimeError`.

* Remove scalpel left in patient

* Don't use a subclass for PyStub error handling

Minor hygiene: most getters in Halide don't have a `get_` prefix. These are very rarely used (only one instance in our test suite I could find) but, hey, cleanliness.

* Add GeneratorFactoryProvider to generate_filter_main()

This provides hooks to allow overriding the Generator(s) that generate_filter_main() can use; normally it defaults to the global registry of C++ Generators, but this allows for (e.g.) alternate-language-bindings to selectively override this (e.g. to enumerate only Generators that are visible in that language, etc).

(No visible change in behavior from this PR; this is just cherry-picked from work-in-progress elsewhere to simplify review & merge)

* Update Generator.cpp

* Fix error handling

This PR proposes to (finally) deprecate disable_llvm_loop_opt:
- make LLVM codegen default to no loop optimization; you must use enable_llvm_loop_opt explicitly to enable it
- disable_llvm_loop_opt still exists, but does nothing (except issue a user_warning that the feature is deprecated)
- Remove various uses of disable_llvm_loop_opt
- Add comments everywhere that the default is different in Halide 15 and that the disable_llvm_loop_opt feature will be removed entirely in Halide 16

Note that all Halide code at Google has defaulted to having disable_llvm_loop_opt set for ~years now, so this is a well-tested codepath, and consensus on the Issue seemed to be that this was a good move.

(Harvested from halide#6757, which probably won't land)

- Add clarifying comment/reference in Generator
- Add assertion to compile_to_multitarget() function
- Fix misleading/wrong code in correctness_compile_to_multitarget

…alide#6762)

A recent bug in LLVM codegen was missed because it only affected x86 architectures with earlier-than-AVX2 SIMD enabled; it didn't show up for AVX2 or later. This revamps correctness_vector_reductions to re-run multiple times when multiple SIMD architectures are available on x86 systems.

(correctness_vector_reductions was chosen here because it reliably demonstrated the specific failures in this case.)

* Fix Param<T>::set_estimate for T=void

* Add tests

halide#6767)

add_python_aot_extension should use FUNCTION_NAME for the .so output (otherwise you can't produce multiple aot extensions from the same Generator)

…lization definitions too (halide#6770)

* Update the list of fused_pairs and run validate_fused_group for specialization definitions too.

Fixes halide#6763.

* Address review comments

* Add const to auto&

halide#6772)

* rename GIOBase::type() and friends

* Func::output_type() -> Func::type()

* Add type() forwarders for inputs

* Add Func::dimensions() wrapper

* Update Func.h

* Fix fundamental confusion about target/tune CPU

Sooo. Uh, remember when in halide#6655
we've agreed that we want to add support to precisely specify
the CPU for which the code should be *tuned* for,
but not *targeted* for. Aka, similar to clang's `-mtune=` option,
that does not affect the ISA set selection?

So guess what, that's not what we did, apparently.
`CodeGen_LLVM::mcpu()` / `halide_mcpu` actually do specify
the *target* CPU. It was obvious in retrospect, because e.g.
`CodeGen_X86::mattrs()` does not, in fact, ever specify `+avx2`,
yet we get AVX2 :) So we've unintentionally added `-march=` support.
Oops.

While i'd like to add `-march=` support, that was not the goal here.

Fixing this is complicated by the fact that
`llvm::Target::createTargetMachine()` only takes `CPU Target` string,
you can't specify `CPU Tune`.

But this is actually a blessing in disguise,
because it allows us to fix another bug at the same time:

There is a problem with halide "compile to llvm ir assembly",
a lot of information from Halide Target is not //really// lowered
into LLVM Module, but is embedded as a metadata,
that is then extracted by halide `make_target_machine()`.

While that is not a problem in itself, it makes it *impossible*
to dump the LLVM IR, and manually play with it,
because e.g. the CPU [Target] and Attributes (ISA set)
are not actually lowered into the form LLVM understands,
but are in some halide-specific metadata.

So, to fix the first bug, we must lower the CPU Tune
into per-function `"tune-cpu"` metadata,
and while there we might as well lower `"target-cpu"`
and `"target-features"` similarly.

* Address review notes

* Hopefully silence bogus issue reported by ancient GCC

* Call `set_function_attributes_from_halide_target_options()` when JIT compiling

* Fix grammar

Update Func.h

This refactors the existing `generate_filter_main()` call in two, moving the interesting implementation of how to drive AOT into the new `execute_generator()` call (reducing `generate_filter_main()` to parsing argc/argv and error reporting).

The new `execute_generator()` is intended to be used (eventually) from Python, as a way to drive Generator compilation from a Python script more easily. The PR doesn't provide a Python wrapper for this call yet (that will come in a subsequent PR).

Also, a drive-by removal of the "error_output" arg to generate_filter_main() -- AFAICT, no one has ever used it for anything but stderr, and the refactoring now just directs all errors to `user_error` uniformly.

…es (halide#6760)

* Allow overriding of `Generator::init_from_context()` for debug purposes

* Update Generator.h

* Attempt to clarify contract

)

…ed (halide#6782)

I'm afraid the problem is really obvious:
https://github.com/halide/Halide/blob/b5f024fa83b6f1cfe5e83a459c9378b7c5bf096d/src/CodeGen_LLVM.cpp#L2628-L2649
^ the shift direction is treated as flippable by the codegen
iff the shift amount is signed :)

The newly-added test fails without the fix.

I've hit this when writing tests for halide#6775

…halide#6787)

Loading plugins and setting the default autoscheduler name both change global state, which isn't a desirable fit for execute_generator(), since it's not intended to mutate global state. (Mutating the state from a main() function is of course a reasonable thing to do.)

)

It's the default after https://reviews.llvm.org/D113210 / llvm/llvm-project@1331728,
but still needs to be done for earlier LLVM's.

Refs. halide#6783
Refs. halide#6718

Partially reverts halide#6718

The ones in HalideRuntime.h have been marked constexpr for a while, but the ones in Float16.h got missed

* AbstractGenerator (rebased, v3)

* Update AbstractGenerator.h

* clang-format

* Update Generator.cpp

* IOKind -> ArgInfoKind

* Various cleanups of AbstractGenerator

* clang-format

* fix pystub

* Update abstractgeneratortest_generator.cpp

* dead code

* ArgInfoDirection

* cleanup

* Delete PyGenerator.cpp

* Update PyStubImpl.cpp

* Update PyStubImpl.cpp

* Fixes from review comments

* Remove `get_` prefix from getters in AbstractGenerator

* Missed some fixes

* Fixes

* Add GeneratorFactoryProvider for generate_filter_main()

* Add GeneratorFactoryProvider to generate_filter_main()

This provides hooks to allow overriding the Generator(s) that generate_filter_main() can use; normally it defaults to the global registry of C++ Generators, but this allows for (e.g.) alternate-language-bindings to selectively override this (e.g. to enumerate only Generators that are visible in that language, etc).

(No visible change in behavior from this PR; this is just cherry-picked from work-in-progress elsewhere to simplify review & merge)

* Update Generator.cpp

* fixes

* Update Generator.cpp

* Restore build_module() and build_gradient_module() methods

* Update Generator.h

* fixes

* Update Generator.cpp

* Update AbstractGenerator.h

It will run otherwise, but is slow on some other targets; rather than trying to (e.g.) shard it, just skip it

…tor size. (halide#6786)

Move vector_bits_* Target support from fixed_width_vectors branch to
make smaller PRs.

* slow tests should support sharding

The simd_op_check test suite is pretty slow (especially for wasm, where it is interpreted); at one point we tried to use ThreadPool to speed it up, but too many pieces of Halide IR aren't threadsafe and we disabled it long ago.

This removes the ThreadPool usage entirely, and instead adds support for the GoogleTest 'sharded test' protocol, which uses certain env vars to allow a test to opt in for splitting its test into smaller pieces.

At present our buildbot isn't attempting to make use of this feature, but it will be a big win for downstream usage in Google, where tests that run "too long" are problematic and splitting them into multiple shards makes various day to day activiites much more pleasant.

* Pacify clang-tidy

Newer versions can warn about "parameter 'f' shadows member inherited from type 'StubOutputBufferBase'", etc -- easy enough

* Update .clang-tidy

* Silence a "possibly uninitialized" warning

At least one compiler thinks we can use this without initialization, which isn't true, but this silences it.

* trigger buildbots

* Step 1

* still more

* Export the error classes so they can be caught

* cleanup

* format

The recent refactoring that added `execute_generator` accidentally nuked setting these two GeneratorParams. Oops. Fixed.

* Rewrite strided loads of 4 in AlignLoads

* Add a check for strided 4 load

…e#6807)

* Fix two minor bugs triggered by a or reduction with early-out

* Gotta print success

* Appease clang-tidy

Add support for vscale vector code generation. Factored from the
fixed_length_vectors branch to make PRs smaller and easier to review.

This will be used to support the ARM SVE/SVE2 and RISC V Vector
architectures.

* reorganize .gitignore

* Add exclusions for CMake build

* .gitignore: comment, drop stale rules

* fully and precisely exclude CMake build tree

* add debugging directions to .gitignore

* ignore CMake install tree

* Sort groups

* Tweak python apps/tutorials for better Blaze/Bazel compatibility

- Don't write to current directory (rely on an env var to say where to write)
- Don't read from arbitrary absolute paths (again, rely on an env var)
- Drive-by removal of unnecessary #include in Codegen_LLVM.cpp inside a lambda (!)

* Recommended fixes

* Revert all changes to tutorial

* Revise apps

* Remove apps_helpers.py

…alide#6830)

This is a bit finicky, but making this the default nomenclature will make some downstream usages less ambiguous and a bit easier to manage. (Yes, I realize that halide#6821 removes the Makefile entirely, but until it lands, it needs fixing there too.)

* Remove Python bindings from Makefiles

* Restore test_li2018 in Makefile (now C++-only)

* Add dummy `test_python` target for buildbots

* Prototype of revised JIT-call convention

Experiment to try out a way to call JIT code in C++ using the same calling conventions as AOT code. Very much experimental.

* Update Pipeline.h

* Add Python support for `compile_to_callable` + make empty_ucon static

* Update PyCallable.cpp

* Update buffer.py

* wip

* Update callable.py

* WIP

* Update custom_allocator.cpp

* Update Callable.cpp

* Add Generator support for Callables

* Update Generator.cpp

* Update PyPipeline.cpp

* Fixes

* Update callable.cpp

* Update CMakeLists.txt

* create_callable_from_generator

* More cleanup

* Update Generator.cpp

* Fix Python bounds inference

* Add Python wrapper for create_callable_from_generator() + Add kwarg support for Callable

* Add set_generatorparam_values() + usage

* Fix auto_schedule/machine_params parsing

The recent refactoring that added `execute_generator` accidentally nuked setting these two GeneratorParams. Oops. Fixed.

* Move the type-checking code into a constexpr code

* Update Callable.h

* clang-tidy

* CLANG-TIDY

* Add `make_std_function`, + more general cleanup

* Update example_jittest.cpp

* Update Callable.h

* Update Callable.h

* More tweaking, smaller CallCheckInfo

* Still more cleanup

* make_std_function now does Buffer type/dim checking where possible

* Add tests for calling `AbstractGenreator::compile_to_callable()` directly

* enable exports

* Various fixes

* Improve fill_slot for Halide::Buffer

* kill report_if_error

* Update callable_bad_arguments.cpp

* Update Pipeline.cpp

* Revise error handling

* Update Callable.cpp

* Update callable.py

* Update callable_generator.cpp

* Update callable.py

* HALIDE_MUST_USE_RESULT -> HALIDE_FUNCTION_ATTRS for Callable

…6836)

* Disable testing for apps/linear_algebra on x86-32-linux/Make

This wasn't biting us before because we were disabling *all* apps/ on x86-32-linux (oops); the recent change to remove python testing under Make also re-enabled this test.

TL;DR: this can probably be made to work somehow, but it's not worth debugging, since that case is both pretty nice, and already covered under CMake. It's literally not worth the time to fix.

* Update Makefile

This is intended to facilitate a few things:
- Move all Generators used in tests, apps, etc to a single directory to simplify the build rules (this is especially useful for the work in halide#6764)
- Put all the test and apps stuff under a single directory to facilitate adding some Python packaging that can make integration into Bazel/Blaze builds a bit less painful

@alexreinking, does this look like the layout we discussed before?

* Better lowering of halving_sub and rounding_halving_add

Previously, lower_halving_sub and lower_rounding_halving_add both used 9
ops. This change redirects halving_sub to use rounding_halving_add, and
redirects rounding_halving_add to use halving_add. In the case that none
of these instructions exist natively, this reduces it to 7/8 ops for
signed/unsigned halving sub and 6 ops for rounding halving add.

More importantly, this lets halving_sub make use of pavgw/b on x86 to
reduce it to 3 ops for u8 and u16 inputs.

* Make signed rounding_halving_add on x86 use pavgb/w too

* Cast result back to signed

* Add explanatory comment

* Fix comment

* Add explanation of signed case