[clang-tools-extra] [llvm] [Support] Remove raw_ostream::tie (PR #97396)

https://github.com/aengelke created https://github.com/llvm/llvm-project/pull/97396 Originally, tie was introduced by D81156 to flush stdout before writing to stderr. 030897523 reverted this due to race conditions. Nonetheless, it does cost performance, causing an extra check in the "cold" pat

[clang-tools-extra] [llvm] [Support] Remove raw_ostream::tie (PR #97396)

https://github.com/aengelke updated https://github.com/llvm/llvm-project/pull/97396 >From 04b794a8a02f06803f96c40de042b13fd4b12c5f Mon Sep 17 00:00:00 2001 From: Alexis Engelke Date: Mon, 1 Jul 2024 16:50:44 +0200 Subject: [PATCH 1/2] [Support] Remove raw_ostream::tie Originally, tie was intro

[clang-tools-extra] [llvm] [Support] Remove raw_ostream::tie (PR #97396)

aengelke wrote: > What I feel the right initial question is, is this check actually making a > significant difference to performance in real-world use cases? raw_ostream::write shows up in my (downstream application) profiles at ~0.6%, mostly through raw_svector_ostream, which is always unbuff

[clang-tools-extra] [llvm] [Support] Move raw_ostream::tie to raw_fd_ostream (PR #97396)

https://github.com/aengelke edited https://github.com/llvm/llvm-project/pull/97396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [Support] Move raw_ostream::tie to raw_fd_ostream (PR #97396)

https://github.com/aengelke edited https://github.com/llvm/llvm-project/pull/97396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [Support] Move raw_ostream::tie to raw_fd_ostream (PR #97396)

https://github.com/aengelke closed https://github.com/llvm/llvm-project/pull/97396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [MC] Remove Darwin SDK/Version from ObjFileInfo (PR #103025)

https://github.com/aengelke created https://github.com/llvm/llvm-project/pull/103025 There's only a single user (MCMachOStreamer), so it makes more sense to move the version emission to the source of the data. (Not sure whether we want this, but I don't see benefits in storing this informatio

[clang] [llvm] [MC] Remove Darwin SDK/Version from ObjFileInfo (PR #103025)

https://github.com/aengelke updated https://github.com/llvm/llvm-project/pull/103025 >From 90c48050f1e56613a4a68056e608de5fdc3e9cb6 Mon Sep 17 00:00:00 2001 From: Alexis Engelke Date: Tue, 13 Aug 2024 09:08:15 + Subject: [PATCH 1/2] [MC] Remove Darwin SDK/Version from ObjFileInfo There's o

[clang] [llvm] [MC] Remove Darwin SDK/Version from ObjFileInfo (PR #103025)

@@ -559,6 +559,9 @@ int main(int argc, char **argv) { std::unique_ptr(CE), *STI)); if (NoExecStack) Str->initSections(true, *STI); +if (TheTriple.isOSBinFormatMachO() && TheTriple.isOSDarwin()) aengelke wrote: No. I just put it in front o

[clang] [llvm] [MC] Remove Darwin SDK/Version from ObjFileInfo (PR #103025)

@@ -109,7 +109,6 @@ initializeRecordStreamer(const Module &M, MCContext MCCtx(TT, MAI.get(), MRI.get(), STI.get(), &SrcMgr); std::unique_ptr MOFI( T->createMCObjectFileInfo(MCCtx, /*PIC=*/false)); - MOFI->setSDKVersion(M.getSDKVersion()); aengelke wr

[clang] [clang-tools-extra] [compiler-rt] [flang] [libc] [libcxx] [lldb] [llvm] [mlir] [InstCombine] Don't look at ConstantData users (PR #103302)

https://github.com/aengelke edited https://github.com/llvm/llvm-project/pull/103302 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [libc] [libcxx] [lldb] [llvm] [mlir] [InstCombine] Don't look at ConstantData users (PR #103302)

https://github.com/aengelke closed https://github.com/llvm/llvm-project/pull/103302 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [MC] Remove Darwin SDK/Version from ObjFileInfo (PR #103025)

https://github.com/aengelke closed https://github.com/llvm/llvm-project/pull/103025 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [MC] Emit a jump table size section (PR #101962)

aengelke wrote: Is there a previous discussion (e.g., RFC) about this? Did you consider alternative approaches? (E.g., just a spontaneous idea, adding a specially named symbol for every jump table where the symbol size is the size of the jump table; entry size (4/8) could be encoded in the nam