These were new in 11.0. The commit adding the options landed after 11.x branch had already been branched off from master, and only then backported to 11.x, so the release notes change stayed for 12.0.
LLVMOrcDisposeObjectLayer and LLVMOrcExecutionSessionGetJITDylibByName did not have matching signatures between the C-API header and binding implementations. Fixes http://llvm.org/PR49745. Patch by Mats Larsen. Thanks Mats! Reviewed by: lhames Differential Revision: https://reviews.llvm.org/D99478 (cherry picked from commit 666df2e2cbe9fc252d3b2d6cbb214c2c2f6afc65)
The `hasIrregularType` predicate checks whether an array of N values of type Ty is "bitcast-compatible" with a <N x Ty> vector. The previous check returned invalid results in some cases where there's some padding between the array elements: eg. a 4-element array of u7 values is considered as compatible with <4 x u7>, even though the vector is only loading/storing 28 bits instead of 32. The problem causes LLVM to generate incorrect code for some targets: for AArch64 the vector loads/stores are lowered in terms of ubfx/bfi, effectively losing the top (N * padding bits). Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D97465 (cherry picked from commit 4f024938e4c932feba4d28573ec4522106f8d879)
The three bit nf is one less than the number of NFIELDS, so we manually decrement 1 for VS1/2/4/8R & VL1/2/4/8R. Differential revision: https://reviews.llvm.org/D98185 (cherry picked from commit rG5cdb2e98608bf57c216ee7067e8a12d070c9e2bd)
The structure of this fold is suspect vs. most of instcombine because it creates instructions and tries to delete them immediately after. If we don't have the operand types for the icmps, then we are not behaving as assumed. And as shown in PR49475, we can inf-loop. (cherry picked from commit 4224a36957420744756d6a6450eb6502a1bfadc3)
PR49475 shows an infinite loop outcome, but this tries to show the root cause with a minimal test. (cherry picked from commit 579b8fc2e97c489308f97b01d13d894c03c0a16c)
If the successor block has a phi node, then additional moves may be inserted into predecessors, which may clobber eflags. Don't try to fold the with.overflow result into the branch in that case. This is done by explicitly checking for any phis in successor blocks, not sure if there's some more principled way to address this. Other fused compare and branch patterns avoid the issue by emitting the comparison when handling the branch, so that no instructions may be inserted in between. In this case, the with.overflow call is emitted separately (and I don't think this is avoidable, as it will generally have at least two users). Fixes https://bugs.llvm.org/show_bug.cgi?id=49587. Differential Revision: https://reviews.llvm.org/D98600 (cherry picked from commit 7669455df49e6fc8ae7d9f4bd4ee95bb20e7eb6e)
Shows a miscompile with FastISel. (cherry picked from commit 0d814ca0f02733d6581bf209fadbebf3035380e0)
All extractvalues of the same value at the same index will map to the same register, so even if one specific extractvalue only has one use, we should not mark it as a trivial kill, as there may be more extractvalues later. Fixes https://bugs.llvm.org/show_bug.cgi?id=49467. Differential Revision: https://reviews.llvm.org/D98145 (cherry picked from commit 55ae279ba7a5905f39ce3ae79eac7834a4a134cc)
Summary: The changes introduced in D87946 changed the API for libomptarget functions. `__kmpc_push_target_tripcount` was a function in Clang 11.x but was not given a backward-compatible interface. This change will require people using Clang 13.x or 12.x to recompile their offloading programs. Reviewed By: jdoerfert cchen Differential Revision: https://reviews.llvm.org/D98358 (cherry picked from commit 807466ef28125cf7268c860b09d5563c9c93602a)