CompilerRT: Normalize COMPILER_RT_DEFAULT_TARGET_TRIPLE (#89234)
If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.
Let's also place libclang_rt into lib/<normalized_triple>.
`libcxx/utils/ci/run-buildbot` is also updated to use
`armv7m-none-unknown-eabi` as normalized triple instead of
current `armv7m-none-eabi`.
ChangeLog of this PR:
This patch has been applied and revert twice:
1. The first try is https://github.com/llvm/llvm-project/pull/88407, and
then it is found that it causes some CI failures.
https://lab.llvm.org/buildbot/#/builders/98/builds/36366
It is then resolved by another commit:
[22 lines not shown]
[InstCombine] Add test to track BPI when condition was inverted (#86469)
InstCombine may invert branch condition and profile metadata. Branch
probability analysis should be updated in this case.
[PatternMatch] Allow poison in api_pred_ty matchers (#89188)
This allows vector splats containing poison for matchers using
api_pred_ty, making the behavior consistent with cst_pred_ty. In other
words, previously `m_NonNegative()` allowed splats with poison, while
`m_NonNegative(C)` did not. Now both allow them.
The affected matchers are m_MaxSignedValue, m_Negative, m_NonNegative,
m_StrictlyPositive, m_NonPositive, m_Power2, m_Power2OrZero,
m_NegatedPower2, m_NegatedPower2OrZero, m_LowBitMask and
m_LowBitMaskOrZero when passing in APInt.
I briefly went through the uses of these matchers and didn't spot any
places where allowing poison would be obviously wrong (I initially
thought foldSelectICmpAndBinOp is problematic, but because it does not
reuse the original constants, it's fine).
A problem here is that, despite these matchers appearing in a decent
number of places, we have very little pre-existing test coverage for
these folds with poison vectors, so we don't benefit from alive2
verification.
[Coverage][NFC] Avoid visiting non-unique `OpaqueValueExpr` (#88910)
Only unique `OpaqueValueExpr`s should be handled in the mapping builder,
as
[discussed](https://github.com/llvm/llvm-project/pull/85837#discussion_r1542056451)
in #85837. However, `getCond()` returns non-unique `OpaqueValueExpr` for
`BinaryConditionalOperator` (because it is also used as the "true"
branch expression). Use `getCommon()` instead so as to bypass the
`OpaqueValueExpr`.
[AsmParser] Support calling intrinsics without mangling suffix (#89172)
This adds proper support for calling intrinsics without mangling suffix
when parsing textual IR. This already worked (mostly by accident) when
only a single mangling suffix was in use.
This patch extends support to the case where the intrinsic is used with
multiple signatures, and as such multiple different intrinsic
declarations have to be inserted. The final IR will have intrinsics with
mangling suffix as usual.
Motivated by the discussion at:
https://discourse.llvm.org/t/recent-improvements-to-the-ir-parser/77366
[InstCombine] Remove some uses with replaceUndefsWith() (#89190)
Now that we don't accept undef splat in PatternMatch, we can remove some
uses of replaceUndefsWith(). I believe in all these cases only poison
splats are possible now, in which case no replacement is necessary.
[clang-cl] [Driver] Fix clang-cl driver supported colon options (#88216)
Tested locally against msvc 1939.
MSVC supports the colon form of various options that take a path even
though that isn't documented for all options on MSDN.
I added the colon form for all supported msvc options that clang-cl does
not intentionally ignore due to being unsupported.
I also fixed the existing colon options by ensure we use
`JoinedOrSeparate`. `/F[x]` argument must used within the same command
line argument. However, `/F[x]:` arguments are allowed to span a command
line argument. The following is valid `/F[x]: path` which is 2 separate
command line arguments.
You can see this documented here,
https://learn.microsoft.com/en-us/cpp/build/reference/fo-object-file-name?view=msvc-170,
where it says `/Fo:[ ]"pathname"`.
This behaviour works for all colon options that take a path and I tested
it locally against msvc 1939 for all the option changes in this PR.
[libc] fix FEnvImpl not using the proxy header (#89303)
In the recent fenv.h header cleanup, two FEnvImpl.h files were missed,
causing build issues. This patch fixes that.
Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext (#89324)
The couple other places that use the oso module's SymbolFile, they check
that it's non-null, so this is just an oversight in
ResolveSymbolContext.
I didn't add a test for this (but did add a log message for the error
case) because I can't see how this would actually happen. The .o file
had to have valid enough DWARF that the linker's parser could handle it
or it would not be in the debug map. If you delete the .o file, we just
leave that entry out of the debug map. If you strip it or otherwise mess
with it, we'll notice the changed mod time and refuse to read it...
This was based on a report from the field, and we don't have access to
the project. But if the logging tells me how this happened I can come
back and add a test with that example.
[hwasan] Add testcase for check-memaccess when using a fixed shadow (#89328)
The test case is based on hwasan-check-memaccess.ll (albeit updated
using update_llc_test_checks) with --hwasan-mapping-offset=...
--hwasan-mapping-offset=... actually doesn't affect the LLVM IR at the
moment; future work will introduce memaccess fixed shadow intrinsics.
(https://github.com/llvm/llvm-project/pull/89319)
adds conversion functions for EI_OSABI in elf (#89280)
These are needed to populate elf headers in core files. This is part of
implementing process save-core in lldb
[Tosa] TosaToLinalg: link in Index dialect (#89318)
This is needed now that this depends on it:
ee0284ec1027b2917afac3da5322553d0f85a759
Co-authored-by: Will Dietz <w at wdtz.org>
[lldb][nfc] Remove unused member Disassembler::m_base_addr (#89289)
This member variable is completely unused. I also don't think it makes a
ton of sense since (1) The "base address" can be obtained from the first
Instruction in its InstructionList, and (2) InstructionLists may not be
a series of contiguous instructions (even though they are most of the
time).
[mlir][llvm] Port `overflowFlags` to a native operation property (#89312)
This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on
operations as native properties.
[DXIL] Add DXIL SubArch to correspond to version number (#89125)
This change is in line with similar notation in SPIRV.
Decoupling version numbering of DXIL and of Shader Model is intended to
enable accurate specification of DXIL features that can be targeted by
different Shader Model versions.
