Initial commit of a tool to help in textual rewrites of .mlir files.
This tool builds of of AsmParserState and is rather simple. Took some
inspiration from when I used clang's AST rewrites where I'd often treat
it as a "localizing" regex applicator in fallback cases, and started
with that as functionality. There though, one does have access to the
lower level info than here, but still a step up over sed over entire
file.
This aims to be helpful (e.g., rewrite syntax including best effort
inside comments) rather than bulletproof tool. It may even be better
suited under utils than tools. And most of the rewrites would be rather
short lived and might never make it upstream (while the helpers of those
rewrites may for future rewrites).
The layering at the moment is not ideal as it is reusing the
RewriteBuffer class from clang's rewrite engine. So only optionally
enabling where clang is also enable. There doesn't seem to be anything
clang specific there (the dep does pull in more dependencies than ideal,
but leaving both refactorings).
Additionally started it as a single file to prototype more easily,
planning to refactor later to include and libs for out of file usage.
https://github.com/llvm/llvm-project/pull/111223 was reverted because of
a build failure with `-DBUILD_SHARED_LIBS=on`.
The Passes component depends on Vectorizer (because PassBuilder needs to
be able to instantiate SandboxVectorizerPass). This resulted in CMake
doing this
1. when it builds lib/libLLVMVectorize.so.20.0git it adds
lib/libLLVMSandboxIR.so.20.0git to the command line, because it's listed
as a dependency (as expected)
2. when it's trying to build lib/libLLVMPasses.so.20.0git it adds
lib/libLLVMVectorize.so.20.0git to the command line, because it's listed
as a dependency (also as expected). But not libLLVMSandboxIR.so.
When SandboxVectorizerPass has its ctors/dtors defined inline, this
caused "undefined reference to vtable" linker errors. This change works
around that by moving ctors/dtors out of line.
Also fix a bazel build problem by adding the new
`llvm/lib/Transforms/Vectorize/SandboxVectorizer/Passes/PassRegistry.def`
as a textual header in the Vectorizer target.
Reverts llvm/llvm-project#108939
When `AVX` is available but `-mprefer-vector-width=128` some of the
`mov` instructions turn into the x86 `rep;movsb` instruction leading to
poor performance on "old" architectures (sandybridge, haswell). The
possible solutions are : get rid of the `-mprefer-vector-width` option
or use smaller static copy sizes in
`inline_memcpy_x86_sse2_ge64_sw_prefetching`. Right now a copy size of 3
cache lines (192B) relying exclusively on xmm registers gets turned into
`rep;movsb`.
While doing an integrate into downstream
https://github.com/iree-org/iree, I ran into a typical Bazel error with
`BasicPtxBuilderInterface.cpp` including `NVVMDialect.h` which was not
exposed as a header by a declared dependency. I tried fixing this the
straightforward way, by letting `:BasicPtxBuilderInterface` depend on
`:NVVMDialect` , but that caused another Bazel error: circular
dependency between these two targets, as `:NVVMDialect` was already
depending on `:BasicPtxBuilderInterface`. I tried breaking that circle
by dropping the latter dependency, but it was a real dependency in the
code, specifically in the TableGen-generated code. So in the end it
seems that these two targets just need to be fused, which this PR does.
Signed-off-by: Benoit Jacob <jacob.benoit.1@gmail.com>
This detail is not relevant for the upstream Bazel version. llvm-libc unit tests today directly invoke the function under test using the namespace, which reduces the potential problems of linking with some other (system-provided) version of llvm-libc further.
Those tools check strict dependency and standalone headers in Google,
but some internal build optimizations caused some violations not to be
detected. This change adds a missing dependency, and includes some types
that are needed for template instantiation.
Anywhere a struct is returned from the kernel, we need to explicitly
unpoison it for MSAN. This patch does that for the recv, recvfrom,
recvmsg, and socketpair functions.
There are no more specializations `libc/src/math/x86_64` or
`libc/src/math/aarch64` anymore. All implementations are going through
the generic implementation.
