[llvm-branch-commits] [clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)

@@ -354,6 +354,23 @@ Given that ``signedPointer`` matches the layout for signed pointers signed with the given key, extract the raw pointer from it. This operation does not trap and cannot fail, even if the pointer is not validly signed. +``ptrauth_sign_constant``

[llvm-branch-commits] [clang] [clang] Define ptrauth_sign_constant builtin. (PR #93904)

efriedma-quic wrote: Why do we want a separate builtin, as opposed to just constant-folding calls to __builtin_ptrauth_sign? https://github.com/llvm/llvm-project/pull/93904 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org

[llvm-branch-commits] [llvm] [release/18.x] Backport fixes for ARM64EC thunk generation (PR #92580)

https://github.com/efriedma-quic approved this pull request. LGTM This only affects Arm64EC targets, the fixes are relatively small, and this affects correctness of generated thunks. https://github.com/llvm/llvm-project/pull/92580 ___

[llvm-branch-commits] [llvm] release/18.x: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)

https://github.com/efriedma-quic approved this pull request. LGTM This only affects optimizations on weak aliases, and the logic is very simple: just don't optimize them. As noted on the original pull request, this also affects some cases which might be safe to optimize (a weak alias where

[llvm-branch-commits] [clang] [llvm] Backport "riscv-isa" module metadata to 18.x (PR #91514)

efriedma-quic wrote: If LTO was completely broken, this seems worth taking. And the changes look safe. LGTM. https://github.com/llvm/llvm-project/pull/91514 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org

[llvm-branch-commits] [clang] [llvm] Backport "riscv-isa" module metadata to 18.x (PR #91514)

efriedma-quic wrote: Can you briefly summarize why this is important to backport? At first glance, this is only relevant for LTO with mixed architecture specifications, which... I can see someone might want it, I guess, but it seems pretty easy to work around not having it.

[llvm-branch-commits] [clang] release/18.x: [clang codegen] Fix MS ABI detection of user-provided constructors. (#90151) (PR #90639)

efriedma-quic wrote: Proposing for backport because this is high-impact for anyone using Qt on Arm64 Windows. https://github.com/llvm/llvm-project/pull/90639 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

efriedma-quic wrote: I think it's worth re-posting the builtin as a separate RFC on Discourse, since the original RFC hadn't settled on the exact design for the clang builtin you're using here. Code changes look fine. https://github.com/llvm/llvm-project/pull/87568

[llvm-branch-commits] [clang] [Clang] Handle structs with inner structs and no fields (#89126) (PR #90133)

efriedma-quic wrote: Looks fine. https://github.com/llvm/llvm-project/pull/90133 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [release/18.x][COFF][Aarch64] Add _InterlockedAdd64 intrinsic (#81849) (PR #89951)

efriedma-quic wrote: I think BuiltinsAArch64.def is part of clang's ABI, so changing it violates the backport rules. Otherwise, I'd be inclined to accept; it's kind of late to request, but it's low risk. https://github.com/llvm/llvm-project/pull/89951

[llvm-branch-commits] [clang] release/18.x: [Clang] Handle structs with inner structs and no fields (#89126) (PR #89456)

efriedma-quic wrote: LGTM This only impacts code using dynamic object sizes, which... I'm not sure how widely it's actually used outside the Linux kernel. Implementation-wise, should be pretty safe. There's some minor risk because the revised recursion visits RecordDecls it wouldn't look

[llvm-branch-commits] [clang] release/18.x [X86_64] fix SSE type error in vaarg (PR #86698)

efriedma-quic wrote: Right, the policy doesn't say we can only take regression fixes. We just need to weight the impact vs. the risk. Looking at the latest conversation on the bug report this case is pretty clearly still broken. It's improved in the sense that after the va_arg of the

[llvm-branch-commits] [llvm] Backport: Prepend all library intrinsics with `#` when building for Arm64EC (PR #88016)

efriedma-quic wrote: LGTM. (This only affects Arm64EC, so it's very safe to backport.) https://github.com/llvm/llvm-project/pull/88016 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org

[llvm-branch-commits] [clang][CallGraphSection] Add type id metadata to indirect call and targets (PR #87573)

@@ -93,9 +93,17 @@ RValue CodeGenFunction::EmitCXXMemberOrOperatorCall( *this, MD, This, ImplicitParam, ImplicitParamTy, CE, Args, RtlArgs); auto = CGM.getTypes().arrangeCXXMethodCall( Args, FPT, CallInfo.ReqArgs, CallInfo.PrefixSize); - return EmitCall(FnInfo,

[llvm-branch-commits] [clang] release/18.x [X86_64] fix SSE type error in vaarg (PR #86698)

efriedma-quic wrote: Is there some reason you think we should take this specific patch, out of all the x86 ABI fixes going in recently? It isn't a regression, as far as I know. https://github.com/llvm/llvm-project/pull/86698 ___ llvm-branch-commits

[llvm-branch-commits] [lld] [llvm] Backport fixes for ARM64EC import libraries (PR #84590)

efriedma-quic wrote: So your use-case is basically equivalent to using llvm-dlltool, except not using the text parser? If this is actually enough to make Rust targets usable, then I guess we could consider it, but the fixes aren't structured in a way to make it obvious this won't impact

[llvm-branch-commits] [lld] [llvm] Backport fixes for ARM64EC import libraries (PR #84590)

efriedma-quic wrote: This seems like a pretty big change to backport... how useful is it in practice? I was under the impression that arm64ec lld support is still immature... and if you're using the MSVC linker, you might as well use the MSVC lib/dlltool.

[llvm-branch-commits] [llvm] Backport ARM64EC variadic args fixes to LLVM 18 (PR #81800)

https://github.com/efriedma-quic approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/81800 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org

[llvm-branch-commits] [clang] release/18.x: [ObjC] Check entire chain of superclasses to determine class layout (PR #84093)

https://github.com/efriedma-quic requested changes to this pull request. We usually only take bugfixes on release branches (miscompiles/crashes/etc.). https://github.com/llvm/llvm-project/pull/84093 ___ llvm-branch-commits mailing list

[llvm-branch-commits] [llvm] release/18.x: [ARM] Switch to LiveRegUnits to fix r7 register allocation bug (PR #84475)

https://github.com/efriedma-quic requested changes to this pull request. This is, as far as I can tell, not a miscompile; probably not worth taking on the 18.x branch. (Also, it's usually not a good idea to open a PR for a cherry-pick before the original patch is merged.)

[llvm-branch-commits] [llvm] Backport ARM64EC variadic args fixes to LLVM 18 (PR #81800)

https://github.com/efriedma-quic commented: Looks fine, but I think merging might need to wait for a point release? CC @tstellar . https://github.com/llvm/llvm-project/pull/81800 ___ llvm-branch-commits mailing list

[llvm-branch-commits] [llvm] Backport ARM64EC variadic args fixes to LLVM 18 (PR #81800)

efriedma-quic wrote: I was sort of waiting until the discussion on #80994 resolves... we might end up reverting parts of #80595 . I guess it won't do any harm to land as-is, though. https://github.com/llvm/llvm-project/pull/81800 ___

[llvm-branch-commits] [llvm] [LivePhysRegs] Add callee-saved regs from MFI in addLiveOutsNoPristines. (PR #73553)

efriedma-quic wrote: Just looked at https://gist.github.com/fhahn/67937125b64440a8a414909c4a1b7973 ; that seems roughly appropriate. It's a little ugly to set the bit to false, then set it back to true, though; I'd rather just explicitly check whether all return instructions are

[llvm-branch-commits] [llvm] [LivePhysRegs] Add callee-saved regs from MFI in addLiveOutsNoPristines. (PR #73553)

efriedma-quic wrote: > After PEI the liveness of LR needs to be accurately reflected and tail calls > could (should?) always "use" LR. That would either prevent outlining or cause > the outliner to preserve LR across introduced calls. I'll elaborate on this a bit. I think long-term, the way

[llvm-branch-commits] [llvm] 4a51298 - [AArch64][SVE] Implement SPLAT_VECTOR for i1 vectors.

Author: Eli Friedman Date: 2019-12-09T15:04:40-08:00 New Revision: 4a51298c13005be05e100f0ef46dbac47623bcd6 URL: https://github.com/llvm/llvm-project/commit/4a51298c13005be05e100f0ef46dbac47623bcd6 DIFF: https://github.com/llvm/llvm-project/commit/4a51298c13005be05e100f0ef46dbac47623bcd6.diff