This command being JITed leads to a substantially worse first-time user
experience, since you have to wait for upwards of 20 seconds for
`fmt.zig` to build. This is especially bad when your editor is
configured to run `zig fmt` on save and does so in a blocking manner. As
such, it makes sense from a usability perspective to not JIT this
particular command.
This seems to be required for ptr_elem_ptr with storage buffers. Note that
this does not imply that the pointer can be regarded as physical too.
Some variants of ptr_elem_ptr will need to be forbidden
From `zig build-exe --help`:
-fno-builtin Disable implicit builtin knowledge of functions
It seems entirely reasonable and even expected that this option should imply
both no-builtins on functions (which disables transformation of recognized code
patterns to libcalls) and nobuiltin on call sites (which disables transformation
of libcalls to intrinsics). We now match Clang's behavior for -fno-builtin.
In both cases, we're painting with a fairly broad brush by applying this to an
entire module, but it's better than nothing. #21833 proposes a more fine-grained
way to apply nobuiltin.
This option, by its very nature, needs to be attached to a module. If it isn't,
the code in a module could break at random when compiled into an application
that doesn't have this option set.
After this change, skip_linker_dependencies no longer implies no_builtin in the
LLVM backend.
The former prevents recognizing code patterns and turning them into libcalls,
which is what we want for compiler-rt. The latter is meant to be used on call
sites to prevent them from being turned into intrinsics.
Context: https://github.com/ziglang/zig/issues/21833
The -lldmingw option affects a lot of logic throughout LLD. We need to pass it
for *-windows-gnu even when we're not actually linking MinGW since we're still
using the MinGW ABI with all that that entails. (One particular problem we would
run into is missing handling of stdcall-decorated symbols for 32-bit x86.) Also,
various other LLD options are sensitive to this option, so it's best to pass it
as early as possible.
Closes#11817.
The old isARM() function was a portability trap. With the name it had, it seemed
like the obviously correct function to use, but it didn't include Thumb. In the
vast majority of cases where someone wants to ask "is the target Arm?", Thumb
*should* be included.
There are exactly 3 cases in the codebase where we do actually need to exclude
Thumb, although one of those is in Aro and mirrors a check in Clang that is
itself likely a bug. These rare cases can just add an extra isThumb() check.
