[PATCH] D34846: Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM's basic block vectorizer. This vectorizer has had no known users for many, many years and is completely surpassed

chandlerc requested review of this revision. chandlerc added a comment. In https://reviews.llvm.org/D34846#796102, @rsmith wrote: > Removing a `-cc1` flag is OK: we explicitly tell people that the `-cc1` > interface is subject to change without notice. What do you think about this now that it

[PATCH] D34846: Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM's basic block vectorizer. This vectorizer has had no known users for many, many years and is completely surpassed

This revision was automatically updated to reflect the committed changes. Closed by commit rL306786: Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM's (authored by chandlerc). Repository: rL LLVM https://reviews.llvm.org/D34846 Files: cfe/trunk/include/clang/Driver/CC1

[PATCH] D35746: Make new PM honor -fdebug-info-for-profiling (clang side)

chandlerc added inline comments. Comment at: lib/CodeGen/BackendUtil.cpp:843 PGOOptions PGOOpt; Maybe make this an optional to avoid the big predicate below? Comment at: lib/CodeGen/BackendUtil.cpp:847-859 if (PGOOpt.RunProfileGen)

[PATCH] D35746: Make new PM honor -fdebug-info-for-profiling (clang side)

chandlerc added a comment. (Also, sorry for the delay reviewing this, for some reason I thought this already got reviewed and landed...) https://reviews.llvm.org/D35746 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/c

[PATCH] D35746: Make new PM honor -fdebug-info-for-profiling (clang side)

chandlerc accepted this revision. chandlerc added a comment. This revision is now accepted and ready to land. LGTM with a tiny tweak below. Would be good to add a test that this flag is being honored, either in this patch or in a follow-up. Comment at: lib/CodeGen/BackendUtil

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

chandlerc added a comment. Just to be explicit, I agree with Hal's summary. This seems like the right engineering tradeoff and I don't find anything particularly unsatisfying about it. In https://reviews.llvm.org/D28404#675616, @mehdi_amini wrote: > Also note that @chandlerc in r290398 made cl

[PATCH] D30806: [nonnull] Teach Clang to attach the nonnull LLVM attribute to declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source c

chandlerc created this revision. Herald added a subscriber: mcrosier. This follows the design direction discussed on cfe-dev here: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html The idea is that for C standard library builtins, even if the library vendor chooses to annotate thei

[PATCH] D30806: [nonnull] Teach Clang to attach the nonnull LLVM attribute to declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source c

chandlerc added a comment. In https://reviews.llvm.org/D30806#697372, @ahatanak wrote: > Are users allowed to call these routines with a null pointer and a non-zero > size? Or can we assume that if the size is known to be non-zero at compile > time, the pointers are not null? If the sizes are

[PATCH] D30806: [nonnull] Teach Clang to attach the nonnull LLVM attribute to declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source c

chandlerc added inline comments. Comment at: lib/AST/ASTContext.cpp:8786 +if (OverrideNonnull && OverrideNonnullArgs) + *OverrideNonnullArgs |= 1 << ArgTypes.size(); + majnemer wrote: > `1U` to avoid overflow UB? I'd mildly prefer an assert (or rely on U

[PATCH] D30806: [nonnull] Teach Clang to attach the nonnull LLVM attribute to declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source c

chandlerc updated this revision to Diff 91286. chandlerc added a comment. Update to fix subtle bugs in handling arguments. Thanks to David for the review comments that caused me to see the issue here. https://reviews.llvm.org/D30806 Files: include/clang/AST/ASTContext.h include/clang/Basic/

[PATCH] D26530: Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.

chandlerc updated this revision to Diff 81008. chandlerc added a comment. Rebase and ping? It'd be awesome to land this minor patch, its been out for a month now. https://reviews.llvm.org/D26530 Files: include/clang/Basic/DiagnosticParseKinds.td include/clang/Basic/DiagnosticSemaKinds.td

[PATCH] D32886: [asan] A clang flag to enable ELF globals-gc

chandlerc accepted this revision. chandlerc added a comment. This revision is now accepted and ready to land. Generally makes sense. A question about the name. Feel free to land with a name that you and other sanitizer folks are happy with. Comment at: include/clang/Driver/Opt

[PATCH] D33467: Fix LLVM build errors if necent build of GCC 7 is used

chandlerc added a comment. What error are you trying to fix? We use flags without `.getValue()` all over the place, I don't know why we would need to change that here. Comment at: lib/Transforms/IPO/PassManagerBuilder.cpp:173 EnablePGOInstrGen = RunPGOInstrGen; -PGOIn

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

chandlerc created this revision. chandlerc added a reviewer: GMNGeoffrey. Herald added a subscriber: mcrosier. chandlerc requested review of this revision. Herald added a reviewer: jdoerfert. Herald added a subscriber: sstefan1. This required substantially more invasive changes I'm afraid. First,

<    1   2   3