Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
This binary is used in LIT tests.
Test: `bazel run --config=generic_clang -c opt @llvm-project//llvm:llvm-remark-size-diff -- --help`
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D121742
D116542 adds EmbedBufferInModule which introduces a layer violation
(https://llvm.org/docs/CodingStandards.html#library-layering).
See 2d5f857a1e for detail.
EmbedBufferInModule does not use BitcodeWriter functionality and should be moved
LLVMTransformsUtils. While here, change the function case to the prevailing
convention.
It seems that EmbedBufferInModule just follows the steps of
EmbedBitcodeInModule. EmbedBitcodeInModule calls WriteBitcodeToFile but has IR
update operations which ideally should be refactored to another library.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D118666
There is a layer violation and can break clang -fmodule-name=X -fmodules-strict-decluse builds:
* LLVMTransformUtils has `#include "llvm/Bitcode/BitcodeWriterPass.h"`
* LLVMBitWriter depends on LLVMTransformUtils after D116542
Temporarily work around the issue.
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
This reverts 3816c53f04 and removes follow-up
fixups.
The original intention was to show error earlier (posix_fallocate time) than
later for ld.lld but it appears to cause some problems which make it not free.
* FreeBSD ZFS: EINVAL, not too bad.
* FreeBSD UFS: according to khng "devastatingly slow on freebsd because UFS on freebsd does not have preallocation support like illumos. It zero-fills."
* NetBSD: maybe EOPNOTSUPP
* Linux tmpfs: unless tmpfs is set up to use huge pages (requires CONFIG_TRANSPARENT_HUGE_PAGECACHE=y), I can consistently demonstrate ~300ms delay for a 1.4GiB output.
* Linux ext4: I don't measure any benefit, either backed by a hard disk or by a file in tmpfs.
* The current code organization of `defined(HAVE_POSIX_FALLOCATE)` costs us a macro dispatch for AIX.
I think we should just remove it. I think if posix_fallocate ever finds demonstrable benefit,
it is likely Linux specific and will not need HAVE_POSIX_FALLOCATE, and possibly opt-in by some specific programs.
In a filesystem with CoW and compression, the ENOSPC benefit may be lost as well.
Reviewed By: khng300
Differential Revision: https://reviews.llvm.org/D115957
This cmake configure option was added in
df0ba47c36, and was ported to
Bazel in 7d323dc773.
However, the setting chosen in Bazel seems accidental, not necessarily
intentional.
LLVM_WINDOWS_PREFER_FORWARD_SLASH has no effect on Unix, and on
Windows, setting it to 0 is the default, which gets the same behaviour
as before. Setting it to 1 enables new experimental behaviours
(which is enabled by default on MinGW targets only).
As I don't see any explicit intent to opt in to the new experimental
behaviour, I believe the current configuration in bazel was a
mistake.
Differential Revision: https://reviews.llvm.org/D114065
They aren't needed anymore, we handle conditional compilation in those
files.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D114970
This required substantially more invasive changes.
We need to handle some of the LLVM `config.h` changes differently from
the old pattern. These aren't always safe on the commandline, and the
Windows ones specifically break Clang. Instead, use conditional defines
in the header itself. This more closely matches how CMake builds see the
definitions. I think this is also just cleaner and we should maybe move
more of the macros out of Bazel.
The config defines for Windows that I've kept in Bazel are the ones that
LLVM's CMake does at the commandline as well. I've also added numerous
ones that CMake uses and we didn't replicate in Bazel.
I also needed a different approach to get `libclang` working well. This,
IMO, improves things on all platforms. Now we build the plugin and
actually wrap it back up with `cc_import`. We have to use a collection
of manually tagged `cc_binary` rules to get the naming to work out the
right way, but this isn't too different from the prior approach. By
directly having a `cc_binary` rule for each platform spelling of
`libclang`, we can actually extract the interface library from it and
correctly depend on it with `cc_import`. I think the result now is much
closer to the intent and to the CMake build for libclang.
Sadly, some tests also needed disabling. This is actually narrower than
what CMake does. The issue isn't indicative of anything serious -- the
test just assumes Unix-style paths.
I also have cleaned up the Windows flags in `.bazelrc` to much more
closely match what CMake does.
Differential Revision: https://reviews.llvm.org/D112399
Adds basic `--config=clang-cl` to set up the basic options needed, and
then fix a number of issues that surface in Windows builds for me.
With these fixes, `//llvm/...` builds cleanly. One unittest still fails,
but its just due to running out of stack space due to creating a large
number of short-lived stack variables. The test should probably be
decomposed into a set of tests (`LegalizerInfoTest::RuleSets`), but that
seemed like too invasive of a change here and with everything building
cleanly this isn't disrupting me experimenting with Windows builds.
Some parts of `//clang/...` builds, but that will require more work.
This is a temporary fix, better would be to avoid including
llvm/Option/ArgList.h from a Support source file.
Differential Revision: https://reviews.llvm.org/D111974
After the TargetRegistry.h move, nothing in Support includes headers
from MC. However, files in tablegen use MC headers, so we must add an
entry for them in tblgen srcs.
Differential Revision: https://reviews.llvm.org/D111835
In attempting to build JAX on Apple Silicon, we discovered an issue with
the bazel configuration in llvm-project-overlay. This patch fixes the
logic, at least when building JAX. More context is included on the
following GitHub issue: https://github.com/google/jax/issues/5501
Differential Revision: https://reviews.llvm.org/D109839
Presently, definitions default to those for Linux which are not defined for FreeBSD (HAVE_LSEEK64, HAVE_MALLINFO, etc.). Patch sets os_defines to posix definitions under FreeBSD.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D109913
There's a lot of unnecessary backslashes here that we can avoid to
reduce confusion.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D108495
Benjamin Kramer