Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation
Sanitizers are different IMO. Different santizers are rather independent,
and there is no such thing as -fsantize to mean -fsantize=all
For PGO, in most of the cases, users do not need to care about the
sub-options implied -- by default they should just get the best profiling
(whatever that is). Fine-grained control is more useful for savvy users.
Besides, any flavor of value profiling usually does not make sense to be
used standalone and need to be used with edge profiling for max benefit
(also not supported in our implementation) - so I don't see why pgo control
needs to be done in a way similar to sanitizers.
In other words, I don't think the primary option -fpgo-train should be
used for fine-grain suboption control. If we have a different option to
do fine-grain control for PGO, using sanitize like syntax is fine with me:
-fpgo-xxx=y:z turn on y and z for pgo
-fno-pgo-xxx=y:z turn off y and z for pgo
or
-fpgo-xxx=no-w:no-y:z turn on z but turn off w, and y
David
On Sat, Jul 2, 2016 at 6:45 PM, Sean Silva wrote:
>
>
> On Sat, Jul 2, 2016 at 1:57 PM, Xinliang David Li
> wrote:
>
>>
>>
>> On Fri, Jul 1, 2016 at 4:32 PM, Sean Silva wrote:
>>
>>> silvas added inline comments.
>>>
>>>
>>> Comment at: lib/Driver/Tools.cpp:3560
>>> @@ +3559,3 @@
>>> +if (PGOTrainArg->getOption().matches(options::OPT_fpgo_train_EQ)) {
>>> + if (StringRef(PGOTrainArg->getValue()) == "source-cfg")
>>> +CmdArgs.push_back("-fprofile-instrument=clang");
>>>
>>> davidxl wrote:
>>> > I think it is better to make the selector 'source' vs 'cfg'.
>>> >
>>> > -fpgo-train=source
>>> > -fpgo-train=cfg
>>> So would `-fpgo-train=cfg` enable icall instrumentation or not?
>>>
>>> My thinking is that down the road we will have one flag for each
>>> independent instrumentation capability (and of course some are mutually
>>> incompatible). This mirrors what the sanitizers do. For example, we would
>>> have:
>>> `-fpgo-train=optimizer-cfg` --> IR edge profiling
>>> `-fpgo-train=optimizer-icall` --> IR icall value profiling
>>> `-fpgo-train=optimizer-...` --> other independent instrumentation we can
>>> do in IR instrumentation.
>>> `-fpgo-train=source-cfg` --> FE edge profiling
>>> `-fpgo-train=source-icall` --> FE icall profiling (if that even exists;
>>> I see some code but there is no user-visible flag)
>>> `-fpgo-train=source-...` --> other FE instrumentation.
>>>
>>> We can then have `-fpgo-train=optimizer` enable e.g.
>>> `-fpgo-train=optimizer-cfg,optimizer-icall`.
>>> We can also have `-fpgo-train=source` enable e.g.
>>> `-fpgo-train=source-cfg`.
>>>
>>> Since instrumentation can have different overheads or different runtime
>>> requirements, users may want to disable some instrumentation.
>>>
>>>
>>
>> -fpgo-train is the new umbrella option that turn on at least edge
>> profiling and some other flavor of value profiling (icall, or stringop, etc
>> in the the future). There is a default setting for source or cfg based PGO.
>> The fine grain control of each sub-option should be done via a different
>> flag -- otherwise we will have to introduce 2 x N sub-options if used with
>> -fpgo-train. In other words, -fpgo-train=cfg turns on edge and icall
>> profiling as of today.
>>
>> To summarize, I think the following behavior will be nice to users:
>>
>> 1) -fpgo-train when used without any option, it defaults to IR pgo (since
>> it is new option)
>> 2) -fpgo-train=cfg (or some other name) turns on IR pgo
>> 3) -fpgo-train=source turns on FE pgo
>>
>> 4) -fpgo-control=edge:icall to turn on edge profiling and icall
>> profiling. Edge will be turn on by default always, so it is redundant to
>> specify. To turn icall off:
>> -fpgo-control=^icall
>>
>
> We have a precedent from the sanitizers that I think we should stick to
> e.g. `-fsanitize=undefined -fno-sanitize=vptr`.
> http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
> http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
>
> I would like to avoid introducing a different syntax (such as the one you
> are proposing using `^` for negation).
>
> -- Sean Silva
>
>
>>
>> 5) -fpgo-train-file= to specify path of raw profile
>>
>> I am not sure if we want -fpgo-apply= as an alias to
>> -fprofile-instr-use=, but not object to it.
>>
>> 6) I also like the capability to combine 1) and 5) by using tags to
>> disambiguate path and cfg|source, but that can be done later.
>>
>> thanks,
>>
>> David
>>
>>
>>
>>
>>>
>>> Repository:
>>> rL LLVM
>>>
>>> http://reviews.llvm.org/D21823
>>>
>>>
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation
On Sat, Jul 2, 2016 at 1:57 PM, Xinliang David Li
wrote:
>
>
> On Fri, Jul 1, 2016 at 4:32 PM, Sean Silva wrote:
>
>> silvas added inline comments.
>>
>>
>> Comment at: lib/Driver/Tools.cpp:3560
>> @@ +3559,3 @@
>> +if (PGOTrainArg->getOption().matches(options::OPT_fpgo_train_EQ)) {
>> + if (StringRef(PGOTrainArg->getValue()) == "source-cfg")
>> +CmdArgs.push_back("-fprofile-instrument=clang");
>>
>> davidxl wrote:
>> > I think it is better to make the selector 'source' vs 'cfg'.
>> >
>> > -fpgo-train=source
>> > -fpgo-train=cfg
>> So would `-fpgo-train=cfg` enable icall instrumentation or not?
>>
>> My thinking is that down the road we will have one flag for each
>> independent instrumentation capability (and of course some are mutually
>> incompatible). This mirrors what the sanitizers do. For example, we would
>> have:
>> `-fpgo-train=optimizer-cfg` --> IR edge profiling
>> `-fpgo-train=optimizer-icall` --> IR icall value profiling
>> `-fpgo-train=optimizer-...` --> other independent instrumentation we can
>> do in IR instrumentation.
>> `-fpgo-train=source-cfg` --> FE edge profiling
>> `-fpgo-train=source-icall` --> FE icall profiling (if that even exists; I
>> see some code but there is no user-visible flag)
>> `-fpgo-train=source-...` --> other FE instrumentation.
>>
>> We can then have `-fpgo-train=optimizer` enable e.g.
>> `-fpgo-train=optimizer-cfg,optimizer-icall`.
>> We can also have `-fpgo-train=source` enable e.g.
>> `-fpgo-train=source-cfg`.
>>
>> Since instrumentation can have different overheads or different runtime
>> requirements, users may want to disable some instrumentation.
>>
>>
>
> -fpgo-train is the new umbrella option that turn on at least edge
> profiling and some other flavor of value profiling (icall, or stringop, etc
> in the the future). There is a default setting for source or cfg based PGO.
> The fine grain control of each sub-option should be done via a different
> flag -- otherwise we will have to introduce 2 x N sub-options if used with
> -fpgo-train. In other words, -fpgo-train=cfg turns on edge and icall
> profiling as of today.
>
> To summarize, I think the following behavior will be nice to users:
>
> 1) -fpgo-train when used without any option, it defaults to IR pgo (since
> it is new option)
> 2) -fpgo-train=cfg (or some other name) turns on IR pgo
> 3) -fpgo-train=source turns on FE pgo
>
> 4) -fpgo-control=edge:icall to turn on edge profiling and icall profiling.
> Edge will be turn on by default always, so it is redundant to specify. To
> turn icall off:
> -fpgo-control=^icall
>
We have a precedent from the sanitizers that I think we should stick to
e.g. `-fsanitize=undefined -fno-sanitize=vptr`.
http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
I would like to avoid introducing a different syntax (such as the one you
are proposing using `^` for negation).
-- Sean Silva
>
> 5) -fpgo-train-file= to specify path of raw profile
>
> I am not sure if we want -fpgo-apply= as an alias to -fprofile-instr-use=,
> but not object to it.
>
> 6) I also like the capability to combine 1) and 5) by using tags to
> disambiguate path and cfg|source, but that can be done later.
>
> thanks,
>
> David
>
>
>
>
>>
>> Repository:
>> rL LLVM
>>
>> http://reviews.llvm.org/D21823
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r274454 - [Refactor NFC] Rename the (non-CCE, fold-failure) Diag during constant expression evaluation as FFDiag.
Author: faisalv
Date: Sat Jul 2 17:34:24 2016
New Revision: 274454
URL: http://llvm.org/viewvc/llvm-project?rev=274454&view=rev
Log:
[Refactor NFC] Rename the (non-CCE, fold-failure) Diag during constant
expression evaluation as FFDiag.
Currently, we have CCEDiags (C++11 core constant expression diags) and Fold
failure diagnostics [I don't claim to yet fully understand exactly why we need
the difference]. This patch explicitly replaces Info.Diag (whose use always
represents a fold failure diag within the file) with Info.FFDiag. This makes
it more easily greppable in the file, and just like the name Info.CCEDiag, it
gives the reader slight further insight into the nature of the diagnostic (as
opposed to Info.Diag).
This patch is a preliminary refactoring step in an effort to allow support for
compatibility-warnings and extensions (such as constexpr lambda) during
constant expression evaluation.
All regressions pass.
Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=274454&r1=274453&r2=274454&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Sat Jul 2 17:34:24 2016
@@ -562,12 +562,12 @@ namespace {
return false;
if (NextCallIndex == 0) {
// NextCallIndex has wrapped around.
-Diag(Loc, diag::note_constexpr_call_limit_exceeded);
+FFDiag(Loc, diag::note_constexpr_call_limit_exceeded);
return false;
}
if (CallStackDepth <= getLangOpts().ConstexprCallDepth)
return true;
- Diag(Loc, diag::note_constexpr_depth_limit_exceeded)
+ FFDiag(Loc, diag::note_constexpr_depth_limit_exceeded)
<< getLangOpts().ConstexprCallDepth;
return false;
}
@@ -584,7 +584,7 @@ namespace {
bool nextStep(const Stmt *S) {
if (!StepsLeft) {
-Diag(S->getLocStart(), diag::note_constexpr_step_limit_exceeded);
+FFDiag(S->getLocStart(), diag::note_constexpr_step_limit_exceeded);
return false;
}
--StepsLeft;
@@ -602,11 +602,10 @@ namespace {
/// Add notes containing a call stack to the current point of evaluation.
void addCallStack(unsigned Limit);
- public:
-/// Diagnose that the evaluation cannot be folded.
-OptionalDiagnostic Diag(SourceLocation Loc, diag::kind DiagId
- = diag::note_invalid_subexpr_in_const_expr,
-unsigned ExtraNotes = 0, bool IsCCEDiag = false) {
+ private:
+OptionalDiagnostic Diag(SourceLocation Loc, diag::kind DiagId,
+unsigned ExtraNotes, bool IsCCEDiag) {
+
if (EvalStatus.Diag) {
// If we have a prior diagnostic, it will be noting that the expression
// isn't a constant expression. This diagnostic is more important,
@@ -651,12 +650,20 @@ namespace {
HasActiveDiagnostic = false;
return OptionalDiagnostic();
}
-
-OptionalDiagnostic Diag(const Expr *E, diag::kind DiagId
+ public:
+// Diagnose that the evaluation could not be folded (FF => FoldFailure)
+OptionalDiagnostic
+FFDiag(SourceLocation Loc,
+ diag::kind DiagId = diag::note_invalid_subexpr_in_const_expr,
+ unsigned ExtraNotes = 0) {
+ return Diag(Loc, DiagId, ExtraNotes, false);
+}
+
+OptionalDiagnostic FFDiag(const Expr *E, diag::kind DiagId
= diag::note_invalid_subexpr_in_const_expr,
-unsigned ExtraNotes = 0, bool IsCCEDiag = false) {
+unsigned ExtraNotes = 0) {
if (EvalStatus.Diag)
-return Diag(E->getExprLoc(), DiagId, ExtraNotes, IsCCEDiag);
+return Diag(E->getExprLoc(), DiagId, ExtraNotes, /*IsCCEDiag*/false);
HasActiveDiagnostic = false;
return OptionalDiagnostic();
}
@@ -666,8 +673,7 @@ namespace {
///
/// FIXME: Stop evaluating if we're in EM_ConstantExpression or
/// EM_PotentialConstantExpression mode and we produce one of these.
-template
-OptionalDiagnostic CCEDiag(LocArg Loc, diag::kind DiagId
+OptionalDiagnostic CCEDiag(SourceLocation Loc, diag::kind DiagId
= diag::note_invalid_subexpr_in_const_expr,
unsigned ExtraNotes = 0) {
// Don't override a previous diagnostic. Don't bother collecting
@@ -678,7 +684,11 @@ namespace {
}
return Diag(Loc, DiagId, ExtraNotes, true);
}
-
+OptionalDiagnostic CCEDiag(const Expr *E, diag::kind DiagId
+ = diag::note_invalid_subexpr_in_const_expr,
+ unsigned ExtraNotes = 0) {
+ return CCEDiag(E->getExprLoc(), DiagId, ExtraNotes);
+}
/// Add a note to a prior diagnostic.
O
Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation
On Fri, Jul 1, 2016 at 4:32 PM, Sean Silva wrote:
> silvas added inline comments.
>
>
> Comment at: lib/Driver/Tools.cpp:3560
> @@ +3559,3 @@
> +if (PGOTrainArg->getOption().matches(options::OPT_fpgo_train_EQ)) {
> + if (StringRef(PGOTrainArg->getValue()) == "source-cfg")
> +CmdArgs.push_back("-fprofile-instrument=clang");
>
> davidxl wrote:
> > I think it is better to make the selector 'source' vs 'cfg'.
> >
> > -fpgo-train=source
> > -fpgo-train=cfg
> So would `-fpgo-train=cfg` enable icall instrumentation or not?
>
> My thinking is that down the road we will have one flag for each
> independent instrumentation capability (and of course some are mutually
> incompatible). This mirrors what the sanitizers do. For example, we would
> have:
> `-fpgo-train=optimizer-cfg` --> IR edge profiling
> `-fpgo-train=optimizer-icall` --> IR icall value profiling
> `-fpgo-train=optimizer-...` --> other independent instrumentation we can
> do in IR instrumentation.
> `-fpgo-train=source-cfg` --> FE edge profiling
> `-fpgo-train=source-icall` --> FE icall profiling (if that even exists; I
> see some code but there is no user-visible flag)
> `-fpgo-train=source-...` --> other FE instrumentation.
>
> We can then have `-fpgo-train=optimizer` enable e.g.
> `-fpgo-train=optimizer-cfg,optimizer-icall`.
> We can also have `-fpgo-train=source` enable e.g. `-fpgo-train=source-cfg`.
>
> Since instrumentation can have different overheads or different runtime
> requirements, users may want to disable some instrumentation.
>
>
-fpgo-train is the new umbrella option that turn on at least edge profiling
and some other flavor of value profiling (icall, or stringop, etc in the
the future). There is a default setting for source or cfg based PGO. The
fine grain control of each sub-option should be done via a different flag
-- otherwise we will have to introduce 2 x N sub-options if used with
-fpgo-train. In other words, -fpgo-train=cfg turns on edge and icall
profiling as of today.
To summarize, I think the following behavior will be nice to users:
1) -fpgo-train when used without any option, it defaults to IR pgo (since
it is new option)
2) -fpgo-train=cfg (or some other name) turns on IR pgo
3) -fpgo-train=source turns on FE pgo
4) -fpgo-control=edge:icall to turn on edge profiling and icall profiling.
Edge will be turn on by default always, so it is redundant to specify. To
turn icall off:
-fpgo-control=^icall
5) -fpgo-train-file= to specify path of raw profile
I am not sure if we want -fpgo-apply= as an alias to -fprofile-instr-use=,
but not object to it.
6) I also like the capability to combine 1) and 5) by using tags to
disambiguate path and cfg|source, but that can be done later.
thanks,
David
>
> Repository:
> rL LLVM
>
> http://reviews.llvm.org/D21823
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r274447 - fix two typos in the doc
Author: sylvestre Date: Sat Jul 2 14:17:58 2016 New Revision: 274447 URL: http://llvm.org/viewvc/llvm-project?rev=274447&view=rev Log: fix two typos in the doc Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst cfe/trunk/docs/doxygen.cfg.in Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SourceBasedCodeCoverage.rst?rev=274447&r1=274446&r2=274447&view=diff == --- cfe/trunk/docs/SourceBasedCodeCoverage.rst (original) +++ cfe/trunk/docs/SourceBasedCodeCoverage.rst Sat Jul 2 14:17:58 2016 @@ -111,7 +111,7 @@ generate a line-oriented report: # Step 3(b): Create a line-oriented coverage report. % llvm-cov show ./foo -instr-profile=foo.profdata -To demangle any C++ identifiers in the ouput, use: +To demangle any C++ identifiers in the output, use: .. code-block:: console Modified: cfe/trunk/docs/doxygen.cfg.in URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/doxygen.cfg.in?rev=274447&r1=274446&r2=274447&view=diff == --- cfe/trunk/docs/doxygen.cfg.in (original) +++ cfe/trunk/docs/doxygen.cfg.in Sat Jul 2 14:17:58 2016 @@ -1937,7 +1937,7 @@ PREDEFINED = EXPAND_AS_DEFINED = # If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will -# remove all refrences to function-like macros that are alone on a line, have an +# remove all references to function-like macros that are alone on a line, have an # all uppercase name, and do not end with a semicolon. Such function macros are # typically used for boiler-plate code, and will confuse the parser if not # removed. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D20795: Added ASTStructure for analyzing the structure of Stmts.
v.g.vassilev requested changes to this revision.
This revision now requires changes to proceed.
Comment at: include/clang/Basic/SourceManager.h:1173
@@ +1172,3 @@
+
+ //
+
A leftover from something else?
Comment at: include/clang/Basic/SourceManager.h:1179
@@ +1178,3 @@
+ /// \returns Returns true if the SourceLocation is expanded from any macro
+ /// body. Returns false if the SourceLocation is invalid, is from not in a
+ /// macro expansion, or is from expanded from a top-level macro argument.
Could you revise the grammar of this entire sentence?
Comment at: lib/AST/ASTStructure.cpp:42
@@ +41,3 @@
+// At this point we know that all Visit* calls for the previous Stmt have
+// finished, so we know save the calculated hash before starting
+// to calculate the next hash.
You meant "now" instead of "know"?
Comment at: lib/AST/ASTStructure.cpp:88
@@ +87,3 @@
+default:
+ return Context.getSourceManager().IsInAnyMacroBody(S->getLocStart()) ||
+ Context.getSourceManager().IsInAnyMacroBody(S->getLocEnd());
I'd add the SourceManager as a member and shorten this code snippet.
Comment at: lib/AST/ASTStructure.cpp:93
@@ +92,3 @@
+
+ // Marks the current Stmt as no to be processed.
+ // Always returns \c true that it can be called
You meant "as not to be"?
Comment at: lib/AST/ASTStructure.cpp:100
@@ +99,3 @@
+
+ // Merges the given value into the current hash code.
+ void CalcHash(unsigned Value) {
Is that the LLVM/Clang common notion for documenting private members: // (i.e.
doxygen disabled) instead of ///
Comment at: lib/AST/ASTStructure.cpp:146
@@ +145,3 @@
+ // All members specify properties of the hash process for the current
+ // Stmt. They are resetted after the Stmt is successfully hased.
+
Why this is dangling? Also "reset".
Comment at: lib/AST/ASTStructure.cpp:202
@@ +201,3 @@
+// invalid code.
+DEF_STMT_VISIT(TypoExpr, { return Skip(); })
+DEF_STMT_VISIT(UnresolvedLookupExpr, { return Skip(); })
Maybe we should issue a warning about it.
Comment at: lib/AST/ASTStructure.cpp:366
@@ +365,3 @@
+ auto numDecls = std::distance(S->decl_begin(), S->decl_end());
+ CalcHash(537u + static_cast(numDecls));
+})
Could we document these "magic" prime numbers and move them in a central place.
I think this would make it more readable.
Comment at: lib/AST/ASTStructure.cpp:404
@@ +403,3 @@
+// TODO: implement hashing custom data of these Stmts
+DEF_STMT_VISIT(AsmStmt, {})
+DEF_STMT_VISIT(MSAsmStmt, {})
Could the implementation of GCCAsmStmt go here in the base class? And
GCCAsmStmt to fall back to the base class (I assume this way we would have
basic support for MSAsmStmt). This holds for the other cases of this pattern,
eg.: *Literal.
Comment at: unittests/AST/ASTStructureTest.cpp:46
@@ +45,3 @@
+
+ auto Hash = ASTStructure(ASTUnit->getASTContext());
+
Why not passing just the ASTContext variable?
Comment at: unittests/AST/ASTStructureTest.cpp:80
@@ +79,3 @@
+
+ auto Hash = ASTStructure(ASTUnit->getASTContext());
+
Same copy-paste here ;) See above.
Comment at: unittests/AST/ASTStructureTest.cpp:103
@@ +102,3 @@
+ auto &ASTContextA = ASTUnitA->getASTContext();
+ auto &ASTContextB = ASTUnitB->getASTContext();
+
I'd move this up and reuse the variables in the rhs of HashA and HashB.
Comment at: unittests/AST/ASTStructureTest.cpp:130
@@ +129,3 @@
+ ASSERT_FALSE(compareStmt("if (true) { int x; }", "if (false) {}"));
+ ASSERT_FALSE(compareStmt("if (int y = 0) {}", "if (false) {}"));
+}
What we will get from compareStmt("if (1 == 2) {}", "if (false) {}")
http://reviews.llvm.org/D20795
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r274442 - [X86][AVX512] Converted the MOVDDUP/MOVSLDUP/MOVSHDUP masked intrinsics to generic IR
Author: rksimon
Date: Sat Jul 2 12:16:25 2016
New Revision: 274442
URL: http://llvm.org/viewvc/llvm-project?rev=274442&view=rev
Log:
[X86][AVX512] Converted the MOVDDUP/MOVSLDUP/MOVSHDUP masked intrinsics to
generic IR
llvm companion patch imminent
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/avx512vl-builtins.c
Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=274442&r1=274441&r2=274442&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Sat Jul 2 12:16:25 2016
@@ -1668,9 +1668,6 @@ TARGET_BUILTIN(__builtin_ia32_movdqa64lo
TARGET_BUILTIN(__builtin_ia32_movdqa64load256_mask,
"V4LLiV4LLiC*V4LLiUc","","avx512vl")
TARGET_BUILTIN(__builtin_ia32_movdqa64store128_mask,
"vV2LLi*V2LLiUc","","avx512f")
TARGET_BUILTIN(__builtin_ia32_movdqa64store256_mask,
"vV4LLi*V4LLiUc","","avx512f")
-TARGET_BUILTIN(__builtin_ia32_movddup512_mask, "V8dV8dV8dUc","","avx512f")
-TARGET_BUILTIN(__builtin_ia32_movddup128_mask, "V2dV2dV2dUc","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_movddup256_mask, "V4dV4dV4dUc","","avx512vl")
TARGET_BUILTIN(__builtin_ia32_pbroadcastb512_gpr_mask,
"V64ccV64cULLi","","avx512bw")
TARGET_BUILTIN(__builtin_ia32_pbroadcastb128_gpr_mask,
"V16ccV16cUs","","avx512bw,avx512vl")
TARGET_BUILTIN(__builtin_ia32_pbroadcastb256_gpr_mask,
"V32ccV32cUi","","avx512bw,avx512vl")
@@ -2122,12 +2119,6 @@ TARGET_BUILTIN(__builtin_ia32_compresssf
TARGET_BUILTIN(__builtin_ia32_compresssi512_mask,
"V16iV16iV16iUs","","avx512f")
TARGET_BUILTIN(__builtin_ia32_cmpsd_mask, "UcV2dV2dIiUcIi","","avx512f")
TARGET_BUILTIN(__builtin_ia32_cmpss_mask, "UcV4fV4fIiUcIi","","avx512f")
-TARGET_BUILTIN(__builtin_ia32_movshdup512_mask, "V16fV16fV16fUs","","avx512f")
-TARGET_BUILTIN(__builtin_ia32_movsldup512_mask, "V16fV16fV16fUs","","avx512f")
-TARGET_BUILTIN(__builtin_ia32_movshdup128_mask, "V4fV4fV4fUc","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_movshdup256_mask, "V8fV8fV8fUc","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_movsldup128_mask, "V4fV4fV4fUc","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_movsldup256_mask, "V8fV8fV8fUc","","avx512vl")
TARGET_BUILTIN(__builtin_ia32_expanddf512_mask, "V8dV8dV8dUc","","avx512f")
TARGET_BUILTIN(__builtin_ia32_expanddi512_mask,
"V8LLiV8LLiV8LLiUc","","avx512f")
TARGET_BUILTIN(__builtin_ia32_expandloaddf512_mask,
"V8dV8dC*V8dUc","","avx512f")
Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=274442&r1=274441&r2=274442&view=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Sat Jul 2 12:16:25 2016
@@ -5572,32 +5572,27 @@ _mm512_mask_store_epi64 (void *__P, __mm
(__mmask8) __U);
}
-
-
static __inline__ __m512d __DEFAULT_FN_ATTRS
_mm512_movedup_pd (__m512d __A)
{
- return (__m512d) __builtin_ia32_movddup512_mask ((__v8df) __A,
- (__v8df)
- _mm512_undefined_pd (),
- (__mmask8) -1);
+ return (__m512d)__builtin_shufflevector((__v8df)__A, (__v8df)__A,
+ 0, 0, 2, 2, 4, 4, 6, 6);
}
static __inline__ __m512d __DEFAULT_FN_ATTRS
_mm512_mask_movedup_pd (__m512d __W, __mmask8 __U, __m512d __A)
{
- return (__m512d) __builtin_ia32_movddup512_mask ((__v8df) __A,
- (__v8df) __W,
- (__mmask8) __U);
+ return (__m512d)__builtin_ia32_selectpd_512((__mmask8)__U,
+ (__v8df)_mm512_movedup_pd(__A),
+ (__v8df)__W);
}
static __inline__ __m512d __DEFAULT_FN_ATTRS
_mm512_maskz_movedup_pd (__mmask8 __U, __m512d __A)
{
- return (__m512d) __builtin_ia32_movddup512_mask ((__v8df) __A,
- (__v8df)
- _mm512_setzero_pd (),
- (__mmask8) __U);
+ return (__m512d)__builtin_ia32_selectpd_512((__mmask8)__U,
+ (__v8df)_mm512_movedup_pd(__A),
+ (__v8df)_mm512_setzero_pd());
}
#define _mm512_fixupimm_round_pd(A, B, C, imm, R) __extension__ ({ \
@@ -8988,53 +8983,47 @@ _mm512_maskz_compress_epi32 (__mmask16 _
static __inline__ __m512 __DEFAULT_FN_ATTRS
_mm512_movehdup_ps (__m512 __A)
{
- return (__m512) __builtin_ia32_movshdup512_mask ((__v16sf) __A,
- (__v16sf)
- _mm512_undefined_ps (),
- (__mmask16) -1);
+ return (__m512)__builtin_shufflevector((__v16sf)__A, (__v16sf)__A,
+
Re: [PATCH] D21385: Adjust Registry interface to not require plugins to export a registry
Ilod added a comment. The PrintFunctionNames plugin works fine, but not the SampleAnalyzerPlugin? The checker-plugins test fails. Not sure, but I suppose it's because the regitration method for checkers is different (a C method called clang_registerCheckers is retrieved in the DLL from the main program, then called with a CheckerRegistry - which is not related with the Registry class - on which a templated method addChecker is called). FAIL: Clang :: Analysis/checker-plugins.c (156 of 9493) TEST 'Clang :: Analysis/checker-plugins.c' FAILED Script: -- Debug/bin/clang.EXE -cc1 -internal-isystem Debug\bin\..\lib\clang\3.9.0\include -nostdsysteminc -load Debug/bin/SampleAnalyzerPlugin.dll -analyze -analyzer-checker='example.MainCallChecker' -verify tools\clang\test\Analysis\checker-plugins.c -- Exit Code: 1 Command Output (stdout): -- $ "Debug/bin/clang.EXE" "-cc1" "-internal-isystem" "Debug\bin\..\lib\clang\3.9.0\include" "-nostdsysteminc" "-load" "Debug/bin/SampleAnalyzerPlugin.dll" "-analyze" "-analyzer-checker=example.MainCallChecker" "-verify" "tools\clang\test\Analysis\checker-plugins.c" # command stderr: CUSTOMBUILD : error : 'error' diagnostics seen but not expected: (frontend): no analyzer checkers are associated with 'example.MainCallChecker' CUSTOMBUILD : error : 'warning' diagnostics expected but not seen: File tools\clang\test\Analysis\checker-plugins.c Line 9: call to main CUSTOMBUILD : error : 'note' diagnostics seen but not expected: (frontend): use -analyzer-disable-all-checks to disable all static analyzer checkers 3 errors generated. CUSTOMBUILD : error : command failed with exit status: 1 Repository: rL LLVM http://reviews.llvm.org/D21385 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r274433 - [CUDA] Move argument type lists to the stack. NFC.
Author: d0k
Date: Sat Jul 2 07:03:57 2016
New Revision: 274433
URL: http://llvm.org/viewvc/llvm-project?rev=274433&view=rev
Log:
[CUDA] Move argument type lists to the stack. NFC.
Modified:
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
Modified: cfe/trunk/lib/CodeGen/CGCUDANV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCUDANV.cpp?rev=274433&r1=274432&r2=274433&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCUDANV.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCUDANV.cpp Sat Jul 2 07:03:57 2016
@@ -189,7 +189,7 @@ llvm::Function *CGNVCUDARuntime::makeReg
// void __cudaRegisterFunction(void **, const char *, char *, const char *,
// int, uint3*, uint3*, dim3*, dim3*, int*)
- std::vector RegisterFuncParams = {
+ llvm::Type *RegisterFuncParams[] = {
VoidPtrPtrTy, CharPtrTy, CharPtrTy, CharPtrTy, IntTy,
VoidPtrTy,VoidPtrTy, VoidPtrTy, VoidPtrTy, IntTy->getPointerTo()};
llvm::Constant *RegisterFunc = CGM.CreateRuntimeFunction(
@@ -213,9 +213,9 @@ llvm::Function *CGNVCUDARuntime::makeReg
// void __cudaRegisterVar(void **, char *, char *, const char *,
//int, int, int, int)
- std::vector RegisterVarParams = {
- VoidPtrPtrTy, CharPtrTy, CharPtrTy, CharPtrTy,
- IntTy,IntTy, IntTy, IntTy};
+ llvm::Type *RegisterVarParams[] = {VoidPtrPtrTy, CharPtrTy, CharPtrTy,
+ CharPtrTy,IntTy, IntTy,
+ IntTy,IntTy};
llvm::Constant *RegisterVar = CGM.CreateRuntimeFunction(
llvm::FunctionType::get(IntTy, RegisterVarParams, false),
"__cudaRegisterVar");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r274432 - Use arrays or initializer lists to feed ArrayRefs instead of SmallVector where possible.
Author: d0k
Date: Sat Jul 2 06:41:41 2016
New Revision: 274432
URL: http://llvm.org/viewvc/llvm-project?rev=274432&view=rev
Log:
Use arrays or initializer lists to feed ArrayRefs instead of SmallVector where
possible.
No functionality change intended
Modified:
cfe/trunk/include/clang/Sema/AttributeList.h
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/Frontend/TestModuleFileExtension.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
Modified: cfe/trunk/include/clang/Sema/AttributeList.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=274432&r1=274431&r2=274432&view=diff
==
--- cfe/trunk/include/clang/Sema/AttributeList.h (original)
+++ cfe/trunk/include/clang/Sema/AttributeList.h Sat Jul 2 06:41:41 2016
@@ -283,11 +283,10 @@ private:
Invalid(false), UsedAsTypeAttr(false), IsAvailability(false),
IsTypeTagForDatatype(false), IsProperty(false), HasParsedType(false),
HasProcessingCache(false), NextInPosition(nullptr), NextInPool(nullptr) {
-ArgsVector Args;
-Args.push_back(Parm1);
-Args.push_back(Parm2);
-Args.push_back(Parm3);
-memcpy(getArgsBuffer(), &Args[0], 3 * sizeof(ArgsUnion));
+ArgsUnion *Args = getArgsBuffer();
+Args[0] = Parm1;
+Args[1] = Parm2;
+Args[2] = Parm3;
AttrKind = getKind(getName(), getScopeName(), syntaxUsed);
}
Modified: cfe/trunk/lib/CodeGen/CGCUDANV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCUDANV.cpp?rev=274432&r1=274431&r2=274432&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCUDANV.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCUDANV.cpp Sat Jul 2 06:41:41 2016
@@ -98,10 +98,7 @@ CGNVCUDARuntime::CGNVCUDARuntime(CodeGen
llvm::Constant *CGNVCUDARuntime::getSetupArgumentFn() const {
// cudaError_t cudaSetupArgument(void *, size_t, size_t)
- std::vector Params;
- Params.push_back(VoidPtrTy);
- Params.push_back(SizeTy);
- Params.push_back(SizeTy);
+ llvm::Type *Params[] = {VoidPtrTy, SizeTy, SizeTy};
return CGM.CreateRuntimeFunction(llvm::FunctionType::get(IntTy,
Params, false),
"cudaSetupArgument");
Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCGNU.cpp?rev=274432&r1=274431&r2=274432&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Sat Jul 2 06:41:41 2016
@@ -1528,21 +1528,17 @@ GenerateMethodList(StringRef ClassName,
IMPTy, //Method pointer
nullptr);
std::vector Methods;
- std::vector Elements;
for (unsigned int i = 0, e = MethodTypes.size(); i < e; ++i) {
-Elements.clear();
llvm::Constant *Method =
TheModule.getFunction(SymbolNameForMethod(ClassName, CategoryName,
MethodSels[i],
isClassMethodList));
assert(Method && "Can't generate metadata for method that doesn't exist");
llvm::Constant *C = MakeConstantString(MethodSels[i].getAsString());
-Elements.push_back(C);
-Elements.push_back(MethodTypes[i]);
Method = llvm::ConstantExpr::getBitCast(Method,
IMPTy);
-Elements.push_back(Method);
-Methods.push_back(llvm::ConstantStruct::get(ObjCMethodTy, Elements));
+Methods.push_back(
+llvm::ConstantStruct::get(ObjCMethodTy, {C, MethodTypes[i], Method}));
}
// Array of method structures
@@ -1585,23 +1581,18 @@ GenerateIvarList(ArrayRef Ivars;
- std::vector Elements;
for (unsigned int i = 0, e = IvarNames.size() ; i < e ; i++) {
-Elements.clear();
-Elements.push_back(IvarNames[i]);
-Elements.push_back(IvarTypes[i]);
-Elements.push_back(IvarOffsets[i]);
-Ivars.push_back(llvm::ConstantStruct::get(ObjCIvarTy, Elements));
+Ivars.push_back(llvm::ConstantStruct::get(
+ObjCIvarTy, {IvarNames[i], IvarTypes[i], IvarOffsets[i]}));
}
// Array of method structures
llvm::ArrayType *ObjCIvarArrayTy = llvm::ArrayType::get(ObjCIvarTy,
IvarNames.size());
-
- Elements.clear();
- Elements.push_back(llvm::ConstantInt::get(IntTy, (int)IvarNames.size()));
- Elements.push_back(llvm::ConstantArray::get(ObjCIvarArrayTy, Ivars));
+ llvm::Constant *Elements[] = {
+ llvm::ConstantInt::get(IntTy, (int)IvarNames.size()),
+ llvm::ConstantArray::get(ObjCIvarArrayTy, Ivars)};
// Structure containing array and array count
llvm::StructType *ObjCIvarListTy = llvm::StructType::get(IntTy,
ObjCIvarArrayTy,
@@ -1713,12 +1704,9 @@ Gene
