Skip to content

[AutoBump] Merge with bba2507c (Dec 04) (19) [Only tested MLIR] #489

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 192 commits into from
Apr 14, 2025
Merged

[AutoBump] Merge with bba2507c (Dec 04) (19) [Only tested MLIR] #489

merged 192 commits into from
Apr 14, 2025

Conversation

@jorickert
Copy link

@jorickert jorickert commented Mar 17, 2025

No description provided.

mingmingl-llvm and others added 30 commits December 2, 2024 16:15
@mingmingl-llvm
[ThinLTO]Supports declaration import for global variables in distribu…
6faf17b 
…ted ThinLTO (llvm#117616)

When `-import-declaration` option is enabled, declaration import is
supported for functions. llvm#88024
has the context for this option.

This patch supports declaration import for global variables in
distributed ThinLTO. The motivating use case is to propagate `dso_local`
attribute of global variables across modules, to optimize global
variable access when a binary is built with
`-fno-direct-access-external-data`.
* With `-fdirect-access-external-data`, non thread-local global
variables will [have `dso_local`
attributes](https://github.com/llvm/llvm-project/blob/fe3c23b439b9a2d00442d9bc6a4ca86f73066a3d/clang/lib/CodeGen/CodeGenModule.cpp#L1730-L1746).
This optimizes the global variable access as shown by
https://gcc.godbolt.org/z/vMzWcKdh3
@mingmingl-llvm
[NFC]Update a ThinLTO test case (llvm#117584)
b2dd4fa 
Run `function-import` pass in a similar way that it runs in a ThinLTO
distributed backend compile and checks that function alias is imported
as a definition. More accurately, the function alias
[is](https://github.com/llvm/llvm-project/blob/0c98776159cea0d1f391a8e1ac290483d4490240/llvm/lib/Transforms/IPO/FunctionImport.cpp#L1912)
a
[clone](https://github.com/llvm/llvm-project/blob/0c98776159cea0d1f391a8e1ac290483d4490240/llvm/lib/Transforms/IPO/FunctionImport.cpp#L1782)
of the aliasee function.
@arsenm @srpande
AMDGPU: Add codegen support for gfx950 v_ashr_pk_i8/u8_i32 (llvm#118304)
b80a157 
Co-authored-by: Sirish Pande <Sirish.Pande@amd.com>
@kastiglione
[lldb] Simplify DumpValueObjectOptions::PointerDepth (NFC) (llvm#117504)
0a96161 
`Mode::Always` and `Mode::Default` are handled identically.
`Mode::Never` is the same as having a count of 0.
@nico
[gn] port 5100307
897dbde
@preames
[RISCV] Fix a typo in a deinterleave test
a2cb208 
This was supposed to test a deinterleave Factor=4, Offset=1, but had an
off by one in the shuffle mask.
@HanKuanChen
[SLP][REVEC] reorderNodeWithReuses should not be called if all users …
f71ea4b 
…of a TreeEntry are ShuffleVectorInst. (llvm#118260)
@sunfishcode @aheejin
[WebAssembly] Define call-indirect-overlong and bulk-memory-opt featu…
c3536b2 
…res (llvm#117087)

This defines some new target features. These are subsets of existing
features that reflect implementation concerns:

- "call-indirect-overlong" - implied by "reference-types"; just the
overlong encoding for the `call_indirect` immediate, and not the actual
reference types.

- "bulk-memory-opt" - implied by "bulk-memory": just `memory.copy` and
`memory.fill`, and not the other instructions in the bulk-memory
proposal.

This is split out from llvm#112035.

---------

Co-authored-by: Heejin Ahn <aheejin@gmail.com>
@fengfeng09
[DAG] Apply Disjoint flag. (llvm#118045)
7907292 
or disjoint (or disjoint (x, c0), c1)
-->
or disjont x, or (c0, c1)
Alive2: https://alive2.llvm.org/ce/z/3wPth5

---------

Signed-off-by: feng.feng <feng.feng@iluvatar.com>
@c8ef
[clang] constexpr built-in elementwise bitreverse function. (llvm#118177
814ed93 
)

Part of llvm#51787.

This patch adds constexpr support for the built-in elementwise
bitreverse function.
@igorkudrin
[ObjectYAML][ELF] Take alignment into account when generating notes (l…
1724188 
…lvm#118157)

The [System V ABI](https://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section)
states that the note entries and their descriptor fields must be aligned
to 4 or 8 bytes for 32-bit or 64-bit objects respectively. In practice,
64-bit systems can use both alignments, with the actual format being
determined by the alignment of the segment. For example, the
[Linux gABI extension](https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf)
contains a special note on this, see 2.1.7 "Alignment of Note Sections".

This patch adjusts the format of the generated notes to the specified
section alignment. Since `llvm-readobj` was fixed in a similar way in
[D150022](https://reviews.llvm.org/D150022), "[Object] Fix handling of
Elf_Nhdr with sh_addralign=8", the generated notes can now be parsed
successfully by the tool.
@lhames
[ORC] Fix typo in comment. NFC.
fb14012
@zyn0217
[Clang] Recover GLTemplateParameterList for generic lambdas in Rebuil…
9ea993f 
…dLambdaScopeInfo (llvm#118176)

The NTTP argument appearing inside a trailing return type of a generic
lambda would have us check for potential lambda captures, where the
function needs GLTemplateParameterList of the current LSI to tell
whether the lambda is generic.

The lambda scope in this context is rebuilt by the
LambdaScopeForCallOperatorInstantiationRAII when substituting the lambda
operator during template argument deduction. Thus, I think the template
parameter list should be preserved in the rebuilding process, as it
seems otherwise innocuous to me.

Fixes llvm#115931
@LiqinWeng
[TTI][RISCV] Implement cost of some intrinsics with LMUL (llvm#117874)
eb3f1ae 
Intrinsics include:
sadd_sat/ssub_sat/uadd_sat/usub_sat/fabs/fsqrt/cttz/ctlz/ctpop
@igorkudrin
Revert "[ObjectYAML][ELF] Take alignment into account when generating…
9597971 
… notes (llvm#118157)"

This reverts commit 1724188.

Some build bots reported a failure in the updated test
@tbaederr
[clang][bytecode] Check __builtin_memcpy for null pointers (llvm#118313)
fc9052e
@preames
[RISCV] Use vcompress in deinterleave2 intrinsic lowering (llvm#118325)
2af2634 
This is analogous to febbf91 which added shuffle lowering using
vcompress; we can do the same thing in the deinterleave2 lowering path
which is used for scalable vectors.

Note that we can further improve this for high lmul usage by adjusting
how we materialize the mask (whose result is at most m1 with a known bit
pattern). I am deliberately staging the work so that the changes to
reduce register pressure are more easily evaluated on their own merit.
@hstk30-hw
[llvm-objdump] Default to --mattr=+all for AArch64be and AArch64_32 (l…
2f5bfb4 
…lvm#118311)

GNU objdump disassembles all unknown instructions by default. 
Complement for [D128030](https://reviews.llvm.org/D128030)。
@cyndyishida
[CompilerRT] Remove sanitizer support for i386 watchsim (llvm#117013)
877b934 
This patch removes remaining support for i386 simulators, watch was the
only one left though.

resolves: rdar://102741146
@dtcxzyw
[InstCombine] Fold (X * (Y << K)) u>> K -> X * Y when highbits are …
295d6b1 
…not demanded (llvm#111151)

Alive2: https://alive2.llvm.org/ce/z/Z7QgjH
@lhames
Re-apply "[ORC] Track all dependencies on symbols that aren't..." wit…
6ef4990 
…h fixes.

This reapplies 427fb5c, which was reverted in 08c1a6b due to bot
failures.

The fix was to remove an incorrect assertion: In IL_emit, during the initial
worklist loop, an EDU can have all of its dependencies removed without becoming
ready (because it may still have implicit dependencies that will be added back
during the subsequent propagateExtraEmitDeps operation). The EDU will be marked
Ready at the end of IL_emit if its Dependencies set is empty at that point.
Prior to that we can only assert that it's either Emitted or Ready (which is
already covered by other assertions).
@lhames
[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Pla…
aba6bb0 
…tforms.

SideEffectsOnly is a new jitlink::Scope value that corresponds to the
JITSymbolFlags::MaterializationSideEffectsOnly flag: Symbols with this scope
can be looked up (and form part of the initial interface of a LinkGraph) but
never actually resolve to an address (so can only be looked up with a
WeaklyReferencedSymbol lookup).

Previously ObjectLinkingLayer implicitly treated JITLink symbols as having this
scope, regardless of a Symbol's actual scope, if the
MaterializationSideEffectsOnly flag was set on the corresponding symbol in the
MaterializationResponsibility object. Using an explicit scope in JITLink for
this (1) allows JITLink plugins to identify and correctly handle
side-effects-only symbols, and (2) allows raw LinkGraphs to define
side-effects-only symbols without clients having to manually modify their
`MaterializationUnit::Interface`.
@lhames
Revert "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in…
28e2a89 
… ORC Platforms."

This reverts commit aba6bb0 while I investigate bot
failures (e.g. https://lab.llvm.org/buildbot/#/builders/143/builds/3848)
@tbaederr
[clang][bytecode][NFC] Diagnose no-constexpr memcpy/strlen versions (l…
dac9736 
…lvm#118429)
@rajatbajpai
[InstCombine][FP] Fix nnan preservation for transform fcmp + sel => f…
de415fb 
…max/fmin (llvm#117977)

Preserve `nnan` constraint only if present on both `fcmp` and `select`.

Alive2: https://alive2.llvm.org/ce/z/ZNDjzt
@tschuett
[GlobalISel] Combine [s,z]ext of undef into 0 (llvm#117439)
4516263 
Alternative for llvm#113764

It builds on a minimalistic approach with the legality check in match
and a blind apply. The precise patterns are used for better compile-time
and modularity. It also moves the pattern check into combiner. While
unary_undef_to_zero and propagate_undef_any_op rely on custom C++ code
for pattern matching.

Is there a limit on the number of patterns?

G_ANYEXT of undef -> undef
G_SEXT of undef -> 0
G_ZEXT of undef -> 0

The combine is not a member of the post legalizer combiner for AArch64.

Test:
llvm/test/CodeGen/AArch64/GlobalISel/combine-cast.mir
@tbaederr
[clang][bytecode] Handle memmove like memcpy (llvm#118431)
7895513 
This is the same thing for us, except for diagnostic differences.
@MaskRay
[InstructionCost] Optimize operator==
e776484 
`!(*this < RHS) && !(RHS < *this)` is difficult for the optimizer to
reason about.
@jayfoad
[AMDGPU] Refine AMDGPUAtomicOptimizerImpl class. NFC. (llvm#118302)
83cbb17 
Use references instead of pointers for most state and common up some of
the initialization between the legacy and new pass manager paths.
@topperc
[RISCV][GISel] Support f64->f32 fptrunc and f32->f64 fpext without D …
9692242 
…extension.

Add RUN lines to float-convert.ll and double-convert.ll without F
extension.
lhames and others added 26 commits December 4, 2024 16:06
@lhames
[ORC] Merge ostream operators for SymbolStringPtrs into SymbolStringP…
3e11ae6 
…ool.h. NFC.

These are simple and commonly used. Having them in the SymbolStringPool header
saves clients from having to #include "DebugUtils.h" everywhere.
@MaskRay
[CodeGen] Fix warning after llvm#115531
932c524
@MaskRay
[lld-link] Replace message(...) with Msg(ctx)
bc66e9a 
to avoid the global ctx.
@kyulee-com
Reapply "[StructuralHash] Global Variable (llvm#118412)"
4f41862 
This reverts commit 6a0d6fc.
@4vtomat
[RISCV] Handle zeroinitializer of vector tuple Type (llvm#113995)
109e4a1 
It doesn't make sense to add a new generic ISD to handle riscv tuple
type. Instead we use `SPLAT_VECTOR` for ISD and further lower to
`VMV_V_X`.

Note: If there's `visitSPLAT_VECTOR` in generic DAG combiner, it needs
to skip riscv vector tuple type.

Stack on llvm#114329
@lhames
[ORC] Move ostream operator for SymbolStringPtrBase into OrcShared.
9c9d4b9 
This will allow clients outside ORC (e.g. JITLink) to use the operator without
taking a dependence on ORC.
@llvmgnsyncbot
[gn build] Port 9c9d4b9
5e7c88b
@topperc
[TargetLowering] Use Type* instead of EVT in shouldSignExtendTypeInLi…
b076fbb 
…bCall. (llvm#118587)

I want to use this function for GISel too so Type * is a better common
interface. All of the callers already convert EVT to Type * as needed
by calling lowering anyway.
@HighCommander4 @qchateau
[clangd] Re-land "support outgoing calls in call hierarchy" (llvm#117673
7be3326 
)

Co-authored-by: Quentin Chateau <quentin.chateau@gmail.com>
@anutosh491
[lld][wasm] Clear lazyBitcodeFiles while resetting context (llvm#118440)
52aff97 
Hi @sbc100 

I was looking into a use case involving the link function (which got my
attention to reset).

I see that `lazyBitcodeFiles` variable was introduced here
llvm#114327 but I don't see it
being reset while destroying the context eventually. Hopefully this
should be the correct way to address it.
@MaskRay
[lld-link] Replace warn(...) with Warn(ctx)
1534f45
@MaskRay
[lld-link] Simplify warnUnusable. NFC
59bc03c
@optimisan
[CodeGen][PM] Use errs() instead of dbgs() in printer passes (llvm#11…
92ed7e2 
…8469)

Printing passes is not exactly a debug activity, it is used in release (and dbgs() is errs() in release)
@ronryvchin
[PGO] Add option to always instrumenting loop entries (llvm#116789)
ff281f7 
This patch extends the PGO infrastructure with an option to prefer the
instrumentation of loop entry blocks.
This option is a generalization of
llvm@19fb5b4,
and helps to cover cases where the loop exit is never executed.
An example where this can occur are event handling loops.

Note that change does NOT change the default behavior.
@lukel97
[RISCV] Mark vmvNr.v as implicitly using vtype (llvm#118414)
5cd3e97 
This was pointed out in
llvm#118283 (comment).
We cannot move these between vtype definitions as they depend on SEW and
require vill to be clear.
@kazutakahirata
[clangd] Fix warnings
94d6b1c 
This patch fixes:

  clang-tools-extra/clangd/XRefs.cpp:2360:11: error: unused type alias
  'SK' [-Werror,-Wunused-local-typedef]

  clang-tools-extra/clangd/XRefs.cpp:2361:10: error: unused variable
  'Kind' [-Werror,-Wunused-variable]
@zyn0217
[Clang] Don't add top-level const qualifiers to captured function typ…
154c7c0 
…es (llvm#118050)

This aligns with the logic in `TreeTransform::RebuildQualifiedType()`
where we refrain from adding const qualifiers to function types.
Previously, we seemed to overlook this edge case when copy-capturing a
variable that is of function type within a const-qualified lambda.

This issue also reveals other related problems as in incorrect type
printout and a suspicious implementation in DeduceTemplateArguments. I
decide to leave them in follow-up work.

Fixes llvm#84961
@RKSimon
[DAG] SimplifyDemandedVectorElts - add handling for INT<->FP conversi…
b1a48af 
…ons (llvm#117884)
@mariusz-sikora-at-amd
[AMDGPU] Emit amdgcn.if.break in the same BB as amdgcn.loop (llvm#118081
455b4fd 
)

Before this change if.break was placed in wrong loop level which
resulted in accumulating values only from last iteration of the inner
loop.
@zero9178
[mlir] Improve error message when number of operands and types differ (…
2a30bfc 
…llvm#118488)

If using a variadic operand, the error message given if the number of
types and operands do not match would be along the lines of:
```
3 operands present, but expected 2
```

This error message is confusing for multiple reasons, particular for
beginners:
* If the intention is to have 3 operands, it does not point out why it
expects 2. The user may actually just want to add a type to the type
list
* It reads as if a verifier error rather than a parser error, giving the
impression the Op only supports 2 operands.

This PR attempts to improve the error message by first noting the issue
("number of operands and types mismatch") and mentioning how many
operands and types it received.
@kwk
[mlir] Specify deps via LLVM_LINK_COMPONENTS (llvm#118542)
4df18ab 
This specifies the dependencies to link against with
`LLVM_LINK_COMPONENTS` for the
`mlir/test/Target/LLVM/MLIRTargetLLVMTests` binary.

Before, the dependencies where directly added to the
`target_link_libraries()` call which caused the problems I describe
next.

When doing a build of LLVM with MLIR I want to link against `libLLVM.so`
instead of statically linking `libLLVMSupport.a`. MLIR on the other side
seems to statically link against `libLLVMSupport.a` because when I link
to the shared library `libLLVM.so` I get:

```
CommandLine Error: Option 'aarch64-ptrauth-auth-checks' registered more than once!
```

This error indicates that the `Support` library is linked twice in the
`MLIRTargetLLVMTest` binary.

Here's the creation of the `MLIRTargetLLVMTest` binary before (Notice
the `libLLVMSupport.a`):

```
[6535/6847] : && /usr/bin/clang++ -O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -D_DEFAULT_SOURCE -Dasm=__asm__ -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wundef -Werror=mismatched-tags -O2 -g -DNDEBUG -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now --config=/usr/lib/rpm/redhat/redhat-hardened-clang-ld.cfg  -flto=thin -ffat-lto-objects -Wl,--build-id=sha1    -Wl,--gc-sections  -fno-lto tools/mlir/unittests/Target/LLVM/CMakeFiles/MLIRTargetLLVMTests.dir/SerializeNVVMTarget.cpp.o tools/mlir/unittests/Target/LLVM/CMakeFiles/MLIRTargetLLVMTests.dir/SerializeROCDLTarget.cpp.o tools/mlir/unittests/Target/LLVM/CMakeFiles/MLIRTargetLLVMTests.dir/SerializeToLLVMBitcode.cpp.o -o tools/mlir/unittests/Target/LLVM/MLIRTargetLLVMTests  -Wl,-rpath,/builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/lib64  lib64/libllvm_gtest_main.a  lib64/libllvm_gtest.a  lib64/libMLIRTargetLLVM.a  lib64/libMLIRNVVMTarget.a  lib64/libMLIRROCDLTarget.a  lib64/libMLIRGPUDialect.a  lib64/libMLIRNVVMDialect.a  lib64/libMLIRLLVMDialect.a  lib64/libMLIRLLVMToLLVMIRTranslation.a  lib64/libMLIRBuiltinToLLVMIRTranslation.a  lib64/libMLIRNVVMToLLVMIRTranslation.a  lib64/libMLIRROCDLToLLVMIRTranslation.a  lib64/libMLIRGPUToLLVMIRTranslation.a  lib64/libLLVMAArch64CodeGen.a  lib64/libLLVMAArch64Desc.a  lib64/libLLVMAArch64Info.a  -lpthread  lib64/libMLIRTargetLLVM.a  lib64/libMLIRROCDLDialect.a  lib64/libMLIRExecutionEngineUtils.a  lib64/libMLIRGPUDialect.a  lib64/libMLIRMemRefDialect.a  lib64/libMLIRArithUtils.a  lib64/libMLIRDialectUtils.a  lib64/libMLIRComplexDialect.a  lib64/libMLIRArithAttrToLLVMConversion.a  lib64/libMLIRArithDialect.a  lib64/libMLIRCastInterfaces.a  lib64/libMLIRDialect.a  lib64/libMLIRInferIntRangeCommon.a  lib64/libMLIRUBDialect.a  lib64/libMLIRShapedOpInterfaces.a  lib64/libMLIRTargetLLVMIRExport.a  lib64/libMLIRDLTIDialect.a  lib64/libMLIRLLVMIRTransforms.a  lib64/libMLIRNVVMDialect.a  lib64/libMLIRLLVMDialect.a  lib64/libMLIRFuncDialect.a  lib64/libMLIRTransforms.a  lib64/libMLIRMemorySlotInterfaces.a  lib64/libMLIRCopyOpInterface.a  lib64/libMLIRRuntimeVerifiableOpInterface.a  lib64/libMLIRTranslateLib.a  lib64/libMLIRParser.a  lib64/libMLIRBytecodeReader.a  lib64/libMLIRAsmParser.a  lib64/libMLIRTransformUtils.a  lib64/libMLIRSubsetOpInterface.a  lib64/libMLIRValueBoundsOpInterface.a  lib64/libMLIRDestinationStyleOpInterface.a  lib64/libMLIRRewrite.a  lib64/libMLIRRewritePDL.a  lib64/libMLIRPDLToPDLInterp.a  lib64/libMLIRPass.a  lib64/libMLIRAnalysis.a  lib64/libMLIRControlFlowInterfaces.a  lib64/libMLIRInferIntRangeInterface.a  lib64/libMLIRCallInterfaces.a  lib64/libMLIRDataLayoutInterfaces.a  lib64/libMLIRViewLikeInterface.a  lib64/libMLIRLoopLikeInterface.a  lib64/libMLIRPresburger.a  lib64/libMLIRPDLInterpDialect.a  lib64/libMLIRFunctionInterfaces.a  lib64/libMLIRPDLDialect.a  lib64/libMLIRSideEffectInterfaces.a  lib64/libMLIRInferTypeOpInterface.a  lib64/libMLIRIR.a  lib64/libMLIRSupport.a  lib64/libLLVM.so.19.1  lib64/libLLVMAArch64Utils.a  lib64/libLLVMAsmPrinter.a  lib64/libLLVMCFGuard.a  lib64/libLLVMGlobalISel.a  lib64/libLLVMSelectionDAG.a  lib64/libLLVMCodeGen.a  lib64/libLLVMScalarOpts.a  lib64/libLLVMAggressiveInstCombine.a  lib64/libLLVMInstCombine.a  lib64/libLLVMBitWriter.a  lib64/libLLVMObjCARCOpts.a  lib64/libLLVMCodeGenTypes.a  lib64/libLLVMTarget.a  lib64/libLLVMVectorize.a  lib64/libLLVMTransformUtils.a  lib64/libLLVMAnalysis.a  lib64/libLLVMProfileData.a  lib64/libLLVMSymbolize.a  lib64/libLLVMDebugInfoDWARF.a  lib64/libLLVMDebugInfoPDB.a  lib64/libLLVMObject.a  lib64/libLLVMMCParser.a  lib64/libLLVMMC.a  lib64/libLLVMIRReader.a  lib64/libLLVMBitReader.a  lib64/libLLVMAsmParser.a  lib64/libLLVMTextAPI.a  lib64/libLLVMDebugInfoCodeView.a  lib64/libLLVMDebugInfoMSF.a  lib64/libLLVMDebugInfoBTF.a  lib64/libLLVMCore.a  lib64/libLLVMBinaryFormat.a  lib64/libLLVMRemarks.a  lib64/libLLVMBitstreamReader.a  lib64/libLLVMTargetParser.a  lib64/libLLVMSupport.a  lib64/libLLVMDemangle.a  -lrt  -ldl  -lm  /usr/lib64/libz.so  /usr/lib64/libzstd.so && :
```

Here's the full error:

```
[24/25] cd /builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/tools/mlir/test && /usr/bin/python3 /builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/./bin/llvm-lit -vv /builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/tools/mlir/test
: CommandLine Error: Option 'aarch64-ptrauth-auth-checks' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
llvm-lit: /builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/utils/lit/lit/formats/googletest.py:38: warning: unable to discover google-tests in '/builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/tools/mlir/unittests/Target/LLVM/./MLIRTargetLLVMTests': Command '['/builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/tools/mlir/unittests/Target/LLVM/./MLIRTargetLLVMTests', '--gtest_list_tests', '--gtest_filter=-*DISABLED_*']' died with <Signals.SIGABRT: 6>.. Process output: b''
error: filter did not match any tests (of 2704 discovered).  Use '--allow-empty-runs' to suppress this error.
FAILED: tools/mlir/test/CMakeFiles/check-mlir /builddir/build/BUILD/llvm-19.1.3-build/llvm-project-19.1.3.src/llvm/redhat-linux-build/tools/mlir/test/CMakeFiles/check-mlir
```

Here's the CMake invocation:

```
/usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja '' -DCLANG_BUILD_EXAMPLES:BOOL=OFF -DCLANG_CONFIG_FILE_SYSTEM_DIR=/etc/clang/ -DCLANG_DEFAULT_PIE_ON_LINUX=OFF -DCLANG_DEFAULT_UNWINDLIB=libgcc -DCLANG_ENABLE_ARCMT:BOOL=ON -DCLANG_ENABLE_STATIC_ANALYZER:BOOL=ON -DCLANG_INCLUDE_DOCS:BOOL=ON -DCLANG_INCLUDE_TESTS:BOOL=ON -DCLANG_LINK_CLANG_DYLIB=ON -DCLANG_PLUGIN_SUPPORT:BOOL=ON '-DCLANG_REPOSITORY_STRING=Fedora 19.1.3-5.fc42' -DLLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=../clang-tools-extra -DCLANG_RESOURCE_DIR=../lib/clang/19 -DCOMPILER_RT_INCLUDE_TESTS:BOOL=OFF -DCOMPILER_RT_INSTALL_PATH=/usr/lib/clang/19 -DLLVM_ENABLE_DOXYGEN:BOOL=OFF -DLLVM_ENABLE_SPHINX:BOOL=ON -DLLVM_BUILD_DOCS:BOOL=ON -DSPHINX_EXECUTABLE=/usr/bin/sphinx-build-3 -DSPHINX_OUTPUT_HTML:BOOL=OFF -DSPHINX_OUTPUT_MAN:BOOL=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF -DLLDB_DISABLE_CURSES:BOOL=OFF -DLLDB_DISABLE_LIBEDIT:BOOL=OFF -DLLDB_DISABLE_PYTHON:BOOL=OFF -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS:BOOL=ON -DLLVM_APPEND_VC_REV:BOOL=OFF -DLLVM_BUILD_EXAMPLES:BOOL=OFF -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON -DLLVM_BUILD_LLVM_DYLIB:BOOL=ON -DLLVM_BUILD_RUNTIME:BOOL=ON -DLLVM_BUILD_TOOLS:BOOL=ON -DLLVM_BUILD_UTILS:BOOL=ON -DLLVM_COMMON_CMAKE_UTILS=/usr/share/llvm/cmake -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-redhat-linux-gnu -DLLVM_DYLIB_COMPONENTS=all -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_FFI:BOOL=ON -DLLVM_ENABLE_LIBCXX:BOOL=OFF -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON '-DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra;lld;lldb;mlir' -DLLVM_ENABLE_RTTI:BOOL=ON '-DLLVM_ENABLE_RUNTIMES=compiler-rt;openmp;offload' -DLLVM_ENABLE_ZLIB:BOOL=ON -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR -DLLVM_INCLUDE_BENCHMARKS=OFF -DLLVM_INCLUDE_EXAMPLES:BOOL=ON -DLLVM_INCLUDE_TOOLS:BOOL=ON -DLLVM_INCLUDE_UTILS:BOOL=ON -DLLVM_INSTALL_TOOLCHAIN_ONLY:BOOL=OFF -DLLVM_INSTALL_UTILS:BOOL=ON -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DLLVM_PARALLEL_LINK_JOBS=1 -DLLVM_TARGETS_TO_BUILD=all -DLLVM_TOOLS_INSTALL_DIR:PATH=bin -DLLVM_UNREACHABLE_OPTIMIZE:BOOL=OFF -DLLVM_USE_PERF:BOOL=ON -DLLVM_UTILS_INSTALL_DIR:PATH=bin -DMLIR_INCLUDE_DOCS:BOOL=ON -DMLIR_INCLUDE_TESTS:BOOL=ON -DMLIR_INCLUDE_INTEGRATION_TESTS:BOOL=OFF -DMLIR_INSTALL_AGGREGATE_OBJECTS=OFF -DMLIR_BUILD_MLIR_C_DYLIB=ON -DMLIR_ENABLE_BINDINGS_PYTHON:BOOL=ON -DOPENMP_INSTALL_LIBDIR=lib64 -DLIBOMP_INSTALL_ALIASES=OFF -DLLVM_BUILD_TESTS:BOOL=ON -DLLVM_INCLUDE_TESTS:BOOL=ON -DLLVM_INSTALL_GTEST:BOOL=ON -DLLVM_LIT_ARGS=-vv -DLLVM_UNITTEST_LINK_FLAGS=-fno-lto -DBUILD_SHARED_LIBS:BOOL=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_LINKER_BUILD_ID:BOOL=ON -DOFFLOAD_INSTALL_LIBDIR=lib64 -DPython3_EXECUTABLE=/usr/bin/python3 -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON -DPPC_LINUX_DEFAULT_IEEELONGDOUBLE=ON -DLLVM_LIBDIR_SUFFIX=64 -DLLVM_BINUTILS_INCDIR=/usr/include -DLLVM_VERSION_SUFFIX=
```
@Maetveis
[clang-repl][CMake][MSVC] Use LINKER: instead of -Wl (llvm#118518)
3b0cb89 
This should be more portable, and avoids passing the option to
`clang-cl` when linking, because `clang-cl` accepts any `-W` flags
(normally warning flags) during linking (llvm#118516).
@optimisan
[CodeGen][NewPM] Port LiveDebugVariables to NPM (llvm#115468)
d9b4bdb 
The existing analysis was already a pimpl wrapper.

I have extracted legacy pass logic to a LDVImpl wrapper named
`LiveDebugVariables` which is the analysis::Result now. This controls
whether to activate the LDV (depending on `-live-debug-variables` and
DIsubprogram) itself.

The legacy and new analysis only construct the LiveDebugVariables.

VirtRegRewriter will test this.
@DavidSpickett
[OpenMP] Add Maintainers.md file
2137ded
@Maetveis
[compiler-rt][MSVC][CMake] Wrap Linker flags for ICX (llvm#118496)
bba2507 
RFC:
https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446

My previous pass missed some flags because I used
`-Werror=unknown-argument`, but `/D`, `/I` and `/O` are accepted by
clang (even when only linking), but mean different things than intended
for `link.exe`.
@jorickert
[AutoBump] Merge with bba2507 (Dec 04)
19f895e
@jorickert jorickert changed the title [AutoBump] Merge with bba2507c (Dec 04) (19) [AutoBump] Merge with bba2507c (Dec 04) (19) [Only tested MLIR] Mar 17, 2025
Base automatically changed from bump_to_7267c859 to bump_to_1b2c8f10 April 14, 2025 07:39
@jorickert jorickert merged commit 336688d into bump_to_1b2c8f10 Apr 14, 2025
11 checks passed
@jorickert jorickert deleted the bump_to_bba2507c branch April 14, 2025 07:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.