[PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB closed this revision. MatzeB added a comment. This was accepted on the mailinglist and committed in r294065 Repository: rL LLVM https://reviews.llvm.org/D29479 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/c

[PATCH] D37891: Driver: hoist the `wchar_t` handling to the driver

MatzeB added inline comments. Comment at: lib/CodeGen/CodeGenModule.cpp:477 Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity(); - assert((LangOpts.ShortWChar || - llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) == ---

[PATCH] D51752: NFC: move isRepeatedBytePattern from clang to Constant

MatzeB added a comment. - I'm not a good person to review clang changes. - I assume the review lacks the changes on the llvm side? - On the LLVM side this feels like something for `Analysis/ValueTracking.h` in fact I already see `Value *isBytewiseValue(Value *V);` there, maybe that is good enoug

[PATCH] D51752: NFC: move isRepeatedBytePattern from clang to Constant

MatzeB added a comment. In https://reviews.llvm.org/D51752#1226462, @MatzeB wrote: > - I assume the review lacks the changes on the llvm side? Oops missed the link to the llvm changes in the description... At least in theory you should be able to make a review over all changes in parallel by

[PATCH] D51752: NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue

MatzeB accepted this revision. MatzeB added a comment. This revision is now accepted and ready to land. Looks obvious and LGTM. Repository: rC Clang https://reviews.llvm.org/D51752 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://li

[PATCH] D43108: Support for the mno-stack-arg-probe flag

MatzeB added a comment. - No test. - What about `-mstack-arg-probe`, shouldn't we have that for consistency? - I'd prefer not to review clang changes myself as I don't know that part of the code too well. Repository: rC Clang https://reviews.llvm.org/D43108 ___

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

MatzeB added a comment. FWIW, I think this makes sense. Moving O0 and optnone get closer seems sensible. Even though -O3 with an optnone function indeed gives you different results today. We are basically maintaining two things for the same "do not optimize" goal. This obviously won't make O0 and

[PATCH] D33711: [TableGen] Clang changes to support Record::getValueAsString and getValueAsListOfStrings returning StringRef instead of std::string

MatzeB accepted this revision. MatzeB added a comment. I assume you have checked that the tablegen output doesn't change. Apart from that I'm all for more StringRef and SmallStrings or even Twines where possible. So LGTM. https://reviews.llvm.org/D33711 _

[PATCH] D37891: Driver: hoist the `wchar_t` handling to the driver

MatzeB added inline comments. Comment at: lib/CodeGen/CodeGenModule.cpp:477 Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity(); - assert((LangOpts.ShortWChar || - llvm::TargetLibraryInfoImpl::getTargetWCharSize(Target.getTriple()) == ---

[PATCH] D37562: [X86] Lower _mm[256|512]_[mask[z]]_avg_epu[8|16] intrinsics to native llvm IR

MatzeB added a comment. With this commit some (old) code stops to compile as it seems to remove some builtins, was that intentional? Reproducer: typedef long long __m128i __attribute__((__vector_size__(16))); typedef short __v8hi __attribute__((__vector_size__(16))); typedef char __v16qi

[PATCH] D37562: [X86] Lower _mm[256|512]_[mask[z]]_avg_epu[8|16] intrinsics to native llvm IR

MatzeB added a comment. Actually, looking at the change it seems like it is and we better try to update emmintrin.h... Repository: rL LLVM https://reviews.llvm.org/D37562 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.

[PATCH] D37562: [X86] Lower _mm[256|512]_[mask[z]]_avg_epu[8|16] intrinsics to native llvm IR

MatzeB added a comment. In https://reviews.llvm.org/D37562#877209, @craig.topper wrote: > Was the code not using emmintrin.h and instead copied code from it that used > the builtins? Turned out to be code that had been preprocessed in the past. I'll unpreprocess the xmmintrin.h/emmintrin.h pa

[PATCH] D40712: Add cc1 flag enabling the function stack size section that was added in r319430

MatzeB added a comment. Looks good to me, but I'm not too familiar with the clang driver code. So it would be good if you could at least add some more experienced clang developers into the reviewer list and wait some more days before committing. I also wonder whether it would be possible to mov

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

MatzeB added inline comments. Herald added a project: All. Comment at: clang/docs/ReleaseNotes.rst:239-243 +- GCC doesn't pack non-POD members in packed structs unless the packed + attribute is also specified on the member. Clang historically did perform + such packing. Clang n

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 430838. Herald added subscribers: cfe-commits, arichardson. Herald added a reviewer: MaskRay. Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://reviews.llvm.org/D1258

[PATCH] D36492: [time-report] Add preprocessor timer

MatzeB added inline comments. Comment at: lib/Lex/Preprocessor.cpp:746 void Preprocessor::Lex(Token &Result) { + llvm::TimeRegion(PPOpts->getTimer()); + modocache wrote: > erik.pilkington wrote: > > Doesn't this just start a timer and immediately end the timer?

[PATCH] D92270: [ConstantFold] Fold more operations to poison

MatzeB added inline comments. Comment at: llvm/lib/IR/ConstantFold.cpp:633 // the input constant. -return UndefValue::get(DestTy); +return PoisonValue::get(DestTy); } I believe this is causing some of our clients trouble, especiall

[PATCH] D137475: Explicitely initialize opaque pointer mode when -fthinlto-index is used

MatzeB created this revision. MatzeB added reviewers: weiwang, aeubanks, nikic, MaskRay. Herald added subscribers: ormris, StephenFan, modimo, wenlei, arphaman, steven_wu, hiraditya, inglorion, mcrosier. Herald added a project: All. MatzeB requested review of this revision. Herald added a project:

[PATCH] D137475: Explicitly initialize opaque pointer mode in CodeGenAction

MatzeB updated this revision to Diff 473747. MatzeB retitled this revision from "Explicitly initialize opaque pointer mode when -fthinlto-index is used" to "Explicitly initialize opaque pointer mode in CodeGenAction". MatzeB edited the summary of this revision. MatzeB added a comment. address re

[PATCH] D137475: Explicitly initialize opaque pointer mode in CodeGenAction

This revision was automatically updated to reflect the committed changes. Closed by commit rGcafe50daf525: Explicitly initialize opaque pointer mode in CodeGenAction (authored by MatzeB). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137475/new/ htt

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

MatzeB added inline comments. Comment at: lld/test/ELF/lto/discard-value-names.ll:4 ; RUN: ld.lld -shared -save-temps %t.o -o %t2.o ; RUN: llvm-dis < %t2.o.0.0.preopt.bc | FileCheck %s bmahjour wrote: > I see `--plugin-opt=opaque-pointers` is being explicitly

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

MatzeB added a comment. @JakeEgan I did a quick look for the code in that stacktrace but nothing jumped out on me. It‘s with inlining effects obscuring it. But I think that crash must be investigated on an AIX machine, there‘s no indication that this directly related to my change which works on

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

MatzeB added a comment. In D125847#3552297 , @MaskRay wrote: > Your commit message seems to use the original summary. Yes sorry, I noticed it too after pushing it. I think this can‘t be fixed after the push though… Repository: rG LLVM Github Monorep

[PATCH] D126334: Move GCC-compatible pod-packing change to v15/old behavior available at v14 and below

MatzeB accepted this revision. MatzeB added a comment. This revision is now accepted and ready to land. LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126334/new/ https://reviews.llvm.org/D126334 __

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 431853. MatzeB marked an inline comment as done. MatzeB added a comment. Enable LTO by default and fix a whole bunch of LTO tests because of it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 432347. MatzeB marked an inline comment as done. MatzeB added a comment. Address review feedback. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://reviews.llvm.org/D125847 Files: clang/lib/Dr

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB marked an inline comment as done. MatzeB added inline comments. Comment at: lld/ELF/Options.td:311 + "Use opaque pointers in IR used during LTO", + "Use typed pointers in IR used during LTO (default)">; + nikic wrote: > `(default)` here is outdated. > >

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 432350. MatzeB marked an inline comment as done. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://reviews.llvm.org/D125847 Files: clang/lib/Driver/ToolChains/CommonArgs.cpp clang/test/CodeGen

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 433577. MatzeB added a comment. address review feedback. I assume this is accepted and good to push when the buildkit builds look reasonable. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://re

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB added inline comments. Comment at: llvm/tools/gold/gold-plugin.cpp:966 + Config.OpaquePointers = options.opaque_pointers; + MaskRay wrote: > `Conf`? > > Ouch, good catch. Guess we have no form of direct testing of the gold plugin in LLVM... Reposit

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB updated this revision to Diff 433591. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://reviews.llvm.org/D125847 Files: clang/lib/Driver/ToolChains/CommonArgs.cpp clang/test/CodeGen/thinlto-inline-asm2.c clang/test/Drive

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

MatzeB added a comment. In D125847#3551972 , @MaskRay wrote: > In D125847#3551841 , @MatzeB wrote: > >> address review feedback. I assume this is accepted and good to push when the >> buildkit builds look reasona

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG850d53a197f9: LTO: Decide upfront whether to use opaque/non-opaque pointer types (authored by MatzeB). Repository: rG LLVM Github Monorepo CHANGE

[PATCH] D125847: LTO: Add option to initialize with opaque/non-opaque pointer types

MatzeB added a comment. In D125847#3554569 , @Jake-Egan wrote: > Hi, this caused `arm-float-abi-lto.c` to fail on AIX. The failure went away > for a few builds, then came back. Could you take a look? > > https://lab.llvm.org/buildbot/#/builders/214/bui

[PATCH] D154658: Optimize emission of `dynamic_cast` to final classes.

MatzeB added a comment. This change results in some of our builds (distributed Thin-LTO in case that matters) to fail with missing symbols. At a first glance this seems to emit VTables in some files where it didn't do this before and then fails to resolve some members of that vtable. I'm in the

[PATCH] D154658: Optimize emission of `dynamic_cast` to final classes.

MatzeB added a comment. In D154658#4533476 , @MatzeB wrote: > This change results in some of our builds (distributed Thin-LTO in case that > matters) to fail with missing symbols. At a first glance this seems to emit > VTables in some files where it did

[PATCH] D157518: Avoid running optimization passes in frontend test

MatzeB created this revision. MatzeB added reviewers: wenlei, Mordante, aeubanks, hoy. Herald added subscribers: modimo, mcrosier. Herald added a project: All. MatzeB requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Only run "lower-expect" b

[PATCH] D157518: Avoid running optimization passes in frontend test

MatzeB updated this revision to Diff 548655. MatzeB added a comment. Decided to just use "utils/update_cc_test_checks.py" so we can inspect the generate llvm.expect calls directly. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157518/new/ https://

[PATCH] D157518: Avoid running optimization passes in frontend test

MatzeB updated this revision to Diff 548657. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157518/new/ https://reviews.llvm.org/D157518 Files: clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp Index: clang/test/CodeGenCXX/attr-likelihoo

[PATCH] D157518: Avoid running optimization passes in frontend test

This revision was automatically updated to reflect the committed changes. Closed by commit rGf8431a0e4008: Avoid running optimization passes in frontend test (authored by MatzeB). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157518/new/ https://rev

[PATCH] D158668: Add getLikelyBranchWeight helper function

MatzeB created this revision. MatzeB added reviewers: lebedev.ri, spatel, davidxl, wenlei, hoy, paulkirth. Herald added subscribers: StephenFan, modimo, hiraditya, mcrosier. Herald added a project: All. MatzeB requested review of this revision. Herald added subscribers: llvm-commits, cfe-commits, w

[PATCH] D158668: Add getLikelyBranchWeight helper function

MatzeB added a comment. Putting this out as a strawman/RFC. Should we add this function to allow LLVM passes to construct "likely"/"unlikely" branch_weights metadata? (I need this in D158642 and D157462 ) Repository: rG LL

[PATCH] D158668: Add getLikelyBranchWeight helper function

MatzeB added a comment. > My initial reaction to this was that we should keep the > --unlikely-branch-weights flag available I don't feel strongly about it and can put it back. But can you give some reasoning? I only see this flag having a real use to express small ratios like 3:2 which doesn'

[PATCH] D158668: Add getLikelyBranchWeight helper function

MatzeB added a comment. > On the other hand, I dislike exposing some internal detail of a pass. I think the question to ask is whether a concept like "likely branch" or "unlikely branch" shouldn't be more universal and not be a pass internal detail? Otherwise it feels like my patches and other

[PATCH] D158668: Add getLikelyBranchWeight helper function

MatzeB added a comment. And as another strawman / discussion-started I put up D158680 where I use `!{"branch_weights", i32 1, i32 0}` to represent likely branches and the actual "LikelyWeight" mostly becomes an internal implementation detail of the BranchProba

[PATCH] D158668: RFC: Add getLikelyBranchWeight helper function

MatzeB added a comment. > I'd also posit, that maybe since we're changing this we should reevaluate the > numbers we use as defaults. Heh, same here. Internally we have a handful of functions that end up using `[[likely]]` loop conditions in a triple-nested loops leading to the estimated block

[PATCH] D158668: RFC: Add getLikelyBranchWeight helper function

MatzeB added a comment. I have a feeling @mtrofin would prefer pass-specific weights rather than a unified notion of "likely"/"unlikely"... So with the latest round of patches it's probably best to abandon this for now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https:/

[PATCH] D157518: Avoid running optimization passes in frontend test

MatzeB marked 2 inline comments as done. MatzeB added inline comments. Comment at: clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp:147-148 -// CHECK: ![[PROF_LIKELY]] = !{!"branch_weights", i32 [[UNLIKELY]], i32 [[LIKELY]]} -// CHECK: ![[PROF_UNLIKELY]] = !{!"branc

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB created this revision. MatzeB added reviewers: GorNishanov, EricWF, ChuanqiXu, bruno. Herald added subscribers: modimo, wenlei, martong, mcrosier. Herald added a reviewer: shafik. Herald added a project: All. MatzeB requested review of this revision. Herald added a project: clang. Herald add

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB added inline comments. Comment at: clang/test/CodeGenCoroutines/coro-function-try-block.cpp:1 +// RUN: %clang_cc1 -std=c++20 -triple=x86_64-- -emit-llvm -fcxx-exceptions \ +// RUN:-disable-llvm-passes %s -o - | FileCheck %s bruno wrote: > Space

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB updated this revision to Diff 508792. MatzeB marked an inline comment as done. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146758/new/ https://reviews.llvm.org/D146758 Files: clang/include/clang/AST/StmtCXX.h clang/lib/AST/ASTImporter.c

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB updated this revision to Diff 509173. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146758/new/ https://reviews.llvm.org/D146758 Files: clang/include/clang/AST/StmtCXX.h clang/lib/AST/ASTImporter.cpp clang/lib/AST/StmtCXX.cpp clang/li

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB added inline comments. Comment at: clang/lib/CodeGen/CGCoroutine.cpp:724-730 + Stmt *BodyStmt = S.getBody(); + CompoundStmt *Body = dyn_cast(BodyStmt); + if (Body == nullptr) { +Body = +CompoundStmt::Create(getContext(), {BodyStmt}, FPOpt

[PATCH] D146758: Fix codegen for coroutine with function-try-block

MatzeB added inline comments. Comment at: clang/lib/CodeGen/CGCoroutine.cpp:724-730 + Stmt *BodyStmt = S.getBody(); + CompoundStmt *Body = dyn_cast(BodyStmt); + if (Body == nullptr) { +Body = +CompoundStmt::Create(getContext(), {BodyStmt}, FPOpt

[PATCH] D146758: Fix codegen for coroutine with function-try-block

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGe00a8d081d78: Fix codegen for coroutine with function-try-block (authored by MatzeB). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTI

[PATCH] D144599: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

MatzeB created this revision. MatzeB added reviewers: kbobyrev, kuganv. Herald added subscribers: modimo, wenlei, kadircet, arphaman, mcrosier. Herald added a project: All. MatzeB requested review of this revision. Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov. Herald added a projec

[PATCH] D144599: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

MatzeB added a comment. I need this change to fix compilation in our environment which uses `grpc-1.42.0`... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144599/new/ https://reviews.llvm.org/D144599 __

[PATCH] D144599: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

MatzeB added a comment. > Asking as it'd be great to know that we've adoption here, outside of > ourselves. I'm not involved in any of this myself. But @kuganv is :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144599/new/ https://reviews.llvm.o

[PATCH] D144599: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

MatzeB updated this revision to Diff 499909. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144599/new/ https://reviews.llvm.org/D144599 Files: clang-tools-extra/clangd/index/remote/monitor/Monitor.cpp Index: clang-tools-extra/clangd/index/remote

[PATCH] D144599: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGc21378f90a44: [clangd/index/remote]NFC: Adapt code to newer grpc/protobuf versions (authored by MatzeB). Repository: rG LLVM Github Monorepo CHAN

[PATCH] D150761: [NFC][Py Reformat] Reformat python files in clang and clang-tools-extra

MatzeB accepted this revision. MatzeB added a comment. This revision is now accepted and ready to land. Inspected 5 random files and they looked fine as expected. Do you know if the test failures are unrealted? LGTM with test failures resolved. Repository: rG LLVM Github Monorepo CHANGES SI

[PATCH] D28505: CGDecl: Skip static variable initializers in unreachable code

MatzeB created this revision. MatzeB added a reviewer: rsmith. MatzeB added a subscriber: cfe-commits. MatzeB set the repository for this revision to rL LLVM. Herald added a subscriber: mcrosier. This fixes http://llvm.org/PR31054 I don't know whether that is the correct fix: Are we actually allo

[PATCH] D29476: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB added a subscriber: cfe-commits. MatzeB added a comment. Add cfe-commits. Repository: rL LLVM https://reviews.llvm.org/D29476 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[PATCH] D29476: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB abandoned this revision. MatzeB added a comment. Abandoning in favor of https://reviews.llvm.org/D29479 because phabricator... Repository: rL LLVM https://reviews.llvm.org/D29476 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

[PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB created this revision. Herald added a subscriber: mcrosier. While there is nothing to do at link time to get pthreads support on darwin, specifying -pthread is fine and should not produce a warning about unused arguments. Repository: rL LLVM https://reviews.llvm.org/D29479 Files: li

[PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB updated this revision to Diff 87023. Repository: rL LLVM https://reviews.llvm.org/D29479 Files: lib/Driver/Tools.cpp test/Driver/darwin-ld-pthread.c Index: test/Driver/darwin-ld-pthread.c === --- /dev/null +++ test/Dr

[PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

MatzeB updated this revision to Diff 87024. MatzeB added a comment. Address review comments: - Simplify test - Only perform the ClaimAll() if we actually link libc, so we get the warning back when combining -nostdlib/-nodefaultlibs with -pthread Repository: rL LLVM https://reviews.llvm.org/

[PATCH] D27005: [lit] Support custom parsers in parseIntegratedTestScript

MatzeB added a comment. This breaks the test-suite lit scripts: Exception during script execution: Traceback (most recent call last): File "/Users/mbraun/dev/public_llvm/utils/lit/lit/run.py", line 183, in execute_test result = test.config.test_format.execute(test, self.lit_config) File

[PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

MatzeB added a comment. Just out of interested: I can see how `__attribute__ ((interrupt))` is useful, but in what situations would you use `no_caller_saved_registers`? https://reviews.llvm.org/D22045 ___ cfe-commits mailing list cfe-commits@lists.

[PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

MatzeB added a comment. In https://reviews.llvm.org/D22045#739627, @MatzeB wrote: > Just out of interested: I can see how `__attribute__ ((interrupt))` is > useful, but in what situations would you use `no_caller_saved_registers`? Actually please answer this question by documenting the attribu