Re: [PATCH] Teach X86 builtins which target features they require
Thank you for the somewhat ridiculous amount of typing there :) Might need some changes when I use it, but obviously having the information there is better than not so LGTM :) -eric On Mon, Aug 3, 2015 at 3:08 PM Justin Bogner m...@justinbogner.com wrote: This adds the required target feature names to x86 builtins that need particular features. Most have exactly one (avx, aes, etc), but some of the avx512 features have multiple requirements, eg avx512vl,avx512bw. Eric: this should be what you need to implement the warning for using functions with unsatisfied target requirements for builtins. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11279: Initial patch for PS4 toolchain
On Thu, Jul 30, 2015 at 10:55 PM Filipe Cabecinhas
filcab+llvm.phabrica...@gmail.com wrote:
filcab planned changes to this revision.
filcab added a comment.
Thank you, Eric.
We'll address the comments and post back an updated patch. Probably make
the linker a separate patch and submit it before we update this one.
Awesome.
I would prefer to not split this into add the toolchain, then fill it out
more (if possible), since we already have this in our internal branch.
Having two bigger merges (especially if one is non-working) or waiting
until we have everything to do the merge wouldn't be ideal.
Seems fair.
Comment at: lib/Driver/Tools.cpp:3115-3118
@@ -3106,6 +3114,6 @@
- // Introduce a Darwin-specific hack. If the default is PIC but the flags
- // specified while enabling PIC enabled level 1 PIC, just force it back
to
- // level 2 PIC instead. This matches the behavior of Darwin GCC (based
on my
- // informal testing).
- if (PIC getToolChain().getTriple().isOSDarwin())
+ // Introduce a Darwin and PS4-specific hack. If the default is PIC but
+ // the flags specified while enabling PIC enabled level 1 PIC, just
+ // force it back to level 2 PIC instead. This matches the behavior of
+ // Darwin GCC (based on my informal testing).
+ if (PIC (getToolChain().getTriple().isOSDarwin() ||
echristo wrote:
If you could rewrite and separate this out a bit more it'd be great.
I'm not the best at it, but I'll try :-)
Sure. Happy to help.
Comment at: lib/Driver/Tools.cpp:3590-3591
@@ -3580,4 +3589,4 @@
Args.ClaimAllArgs(options::OPT_g_flags_Group);
if (Args.hasFlag(options::OPT_gcolumn_info,
options::OPT_gno_column_info,
- /*Default*/ true))
+ /*Default*/ !Triple.isPS4CPU()))
CmdArgs.push_back(-dwarf-column-info);
echristo wrote:
Hmm?
We have different defaults from other platforms.
Yeah, not commented (because it's not /*Default*/. Might be nice to
refactor this out slightly? It just a little gross at the moment.
Comment at: lib/Driver/Tools.cpp:3613
@@ -3603,3 +3612,3 @@
// backend.
- if (Args.hasArg(options::OPT_gdwarf_aranges)) {
+ if (Args.hasArg(options::OPT_gdwarf_aranges) || Triple.isPS4CPU()) {
CmdArgs.push_back(-backend-option);
echristo wrote:
Ditto.
Ditto, different defaults.
But I guess I can hoist out the Triple.isPS4CPU() on both cases, if you
prefer, like it's done for other toolchains like:
bool IsWindowsMSVC =
getToolChain().getTriple().isWindowsMSVCEnvironment();
Seems reasonable. I'm not sure how else to refactor it out well.
Comment at: lib/Driver/Tools.cpp:9435-9436
@@ +9434,4 @@
+
+ const char *Exec =
+ Args.MakeArgString(getToolChain().GetProgramPath(ps4-as));
+ C.addCommand(llvm::make_uniqueCommand(JA, *this, Exec, CmdArgs,
Inputs));
echristo wrote:
Using an external assembler rather than the integrated one?
We support both (but default to integrated, since we don't override
`Generic_GCC::IsIntegratedAssemblerDefault()`).
Oh right, and it's just a different name. OK, that makes sense, thanks.
Comment at: lib/Driver/Tools.h:783
@@ -782,1 +782,3 @@
+namespace PS4cpu {
+class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
echristo wrote:
Hrm. PS4 maybe? PS4cpu seems to say that it's a custom cpu target and
not a custom environment?
PS4cpu (or PS4CPU) is more consistent with how we've been naming things in
open source.
Okie.
Thanks!
-eric
http://reviews.llvm.org/D11279
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r239883 - Update the intel intrinsic headers to use the target attribute support.
Where are the negative test cases? Diagnosing uses of these functions when they aren't valid is really important - it's a pretty serious regression if we don't. Two threads, I'm going to take this in the other thread. :) -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11279: Initial patch for PS4 toolchain
echristo added a comment. ? http://reviews.llvm.org/D11279 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11279: Initial patch for PS4 toolchain
echristo added a comment.
Added a bunch of inline comments. The easiest way for this is probably going to
be to split this out into a few separate patches where we get the skeleton in
and then start filling it out.
Thanks!
-eric
Comment at: include/clang/Basic/DiagnosticDriverKinds.td:203-208
@@ +202,8 @@
+ InGroupInvalidOrNonExistentDirectory;
+def warn_drv_ps4_sdk_include : Warning
+ unable to find PS4 system headers directory, expected to be in '%0',
+ InGroupInvalidOrNonExistentDirectory;
+def warn_drv_ps4_sdk_lib : Warning
+ unable to find PS4 system libraries directory, expected to be in '%0',
+ InGroupInvalidOrNonExistentDirectory;
+
Are the existing header warnings insufficient?
Comment at: include/clang/Driver/Options.td:1159-1160
@@ -1158,2 +1158,4 @@
def lazy__library : Separate[-], lazy_library, Flags[LinkerInput];
+def linker : Separate[-], linker, HelpTextUse linker name,
MetaVarNamename;
+def linker_EQ : Joined[-], linker=, Aliaslinker;
def mlittle_endian : Flag[-], mlittle-endian, Flags[DriverOption];
Can this be done separately?
Comment at: lib/Driver/Tools.cpp:3115-3118
@@ -3106,6 +3114,6 @@
- // Introduce a Darwin-specific hack. If the default is PIC but the flags
- // specified while enabling PIC enabled level 1 PIC, just force it back to
- // level 2 PIC instead. This matches the behavior of Darwin GCC (based on my
- // informal testing).
- if (PIC getToolChain().getTriple().isOSDarwin())
+ // Introduce a Darwin and PS4-specific hack. If the default is PIC but
+ // the flags specified while enabling PIC enabled level 1 PIC, just
+ // force it back to level 2 PIC instead. This matches the behavior of
+ // Darwin GCC (based on my informal testing).
+ if (PIC (getToolChain().getTriple().isOSDarwin() ||
If you could rewrite and separate this out a bit more it'd be great.
Comment at: lib/Driver/Tools.cpp:3590-3591
@@ -3580,4 +3589,4 @@
Args.ClaimAllArgs(options::OPT_g_flags_Group);
if (Args.hasFlag(options::OPT_gcolumn_info, options::OPT_gno_column_info,
- /*Default*/ true))
+ /*Default*/ !Triple.isPS4CPU()))
CmdArgs.push_back(-dwarf-column-info);
Hmm?
Comment at: lib/Driver/Tools.cpp:3613
@@ -3603,3 +3612,3 @@
// backend.
- if (Args.hasArg(options::OPT_gdwarf_aranges)) {
+ if (Args.hasArg(options::OPT_gdwarf_aranges) || Triple.isPS4CPU()) {
CmdArgs.push_back(-backend-option);
Ditto.
Comment at: lib/Driver/Tools.cpp:9435-9436
@@ +9434,4 @@
+
+ const char *Exec =
+ Args.MakeArgString(getToolChain().GetProgramPath(ps4-as));
+ C.addCommand(llvm::make_uniqueCommand(JA, *this, Exec, CmdArgs, Inputs));
Using an external assembler rather than the integrated one?
Comment at: lib/Driver/Tools.cpp:9733-9736
@@ +9732,6 @@
+
+ if (PS4Linker)
+ConstructPS4LinkJob(*this, C, JA, Output, Inputs, Args, LinkingOutput);
+ else
+ConstructGoldLinkJob(*this, C, JA, Output, Inputs, Args, LinkingOutput);
+}
Based on this (and the above code) might we want an enum set of options to the
linker bit? How about we split up this patch and leave the linker option
separate and we can talk about and add that bit after?
Comment at: lib/Driver/Tools.h:783
@@ -782,1 +782,3 @@
+namespace PS4cpu {
+class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
Hrm. PS4 maybe? PS4cpu seems to say that it's a custom cpu target and not a
custom environment?
Comment at: lib/Frontend/InitHeaderSearch.cpp:325-344
@@ +324,22 @@
+ case llvm::Triple::PS4: {
+// isysroot gets prepended later in AddPath().
+std::string BaseSDKPath = ;
+if (!HasSysroot) {
+ const char *envValue = getenv(SCE_PS4_SDK_DIR);
+ if (envValue)
+BaseSDKPath = envValue;
+ else {
+// HSOpts.ResourceDir variable contains the location of Clang's
+// resource files.
+// Assuming that Clang is configured for PS4 without
+// --with-clang-resource-dir option, the location of Clang's resource
+// files is SDK_DIR/host_tools/lib/clang
+SmallString128 P = StringRef(HSOpts.ResourceDir);
+llvm::sys::path::append(P, ../../..);
+BaseSDKPath = P.str();
+ }
+}
+AddPath(BaseSDKPath + /target/include, System, false);
+if (triple.isPS4CPU())
+ AddPath(BaseSDKPath + /target/include_common, System, false);
+ }
This all seems odd, what's going on here?
http://reviews.llvm.org/D11279
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11575: Silence unused argument warning for --cuda-host-only.
echristo accepted this revision. echristo added a comment. Sure. It's probably not ideal, but seems to work. Couple of silly nits inline. -eric Comment at: test/Driver/cuda-options.cu:72 @@ -71,1 +71,3 @@ +// --cuda-host-only should not ever trigger unused arg warning. +// RUN: %clang -### -target x86_64-linux-gnu --cuda-host-only -c %s 21 | \ not ever - never Comment at: test/Driver/cuda-options.cu:78 @@ +77,3 @@ + +// --cuda-device-only should not produce warnging compiling CUDA files +// RUN: %clang -### -target x86_64-linux-gnu --cuda-device-only -c %s 21 | \ samsonov wrote: s/warnging/warning warning http://reviews.llvm.org/D11575 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11573: --cuda-host-only should not disable linking phase.
echristo accepted this revision. echristo added a comment. One inline comment. -eric Comment at: test/Driver/cuda-options.cu:30 @@ -29,3 +29,3 @@ // RUN:-check-prefix CUDA-H -check-prefix CUDA-H-NI \ -// Make sure we don't link anything. -// RUN:-check-prefix CUDA-NL %s +// Make linking is allowed to happen, even if we're missing GPU code. +// RUN:-check-prefix CUDA-L %s Grammar? http://reviews.llvm.org/D11573 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11338: [X86] Add missing _m_prefetch intrinsic
echristo accepted this revision. echristo added a comment. This revision is now accepted and ready to land. LGTM. -eric Repository: rL LLVM http://reviews.llvm.org/D11338 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10476: Additional fix for PR14269: Clang crashes when a bit field is used as inline assembler input / output with memory constraint
echristo accepted this revision. echristo added a comment. This revision is now accepted and ready to land. In http://reviews.llvm.org/D10476#209500, @hfinkel wrote: In http://reviews.llvm.org/D10476#203538, @andreybokhanko wrote: In http://reviews.llvm.org/D10476#202740, @hfinkel wrote: I agree; we don't want to tie frontend functionality to a specific representation of the vectors. We could support this, but we'd need to do it by: 1. Creating a local stack variable (alloca) 2. Extracting the requested vector element and storing it in that stack-allocated memory 3. Providing the address of the local stack variable to the inline asm 4. After the inline asm, loading the value from the local stack variable and inserting it back into the vector I have no opinion on whether or not this is worth implementing. Hal, what you suggested means basically creating a new local variable, copying value of a vector element to it and then providing address of this local variable, **not** original vector element. I'm not sure that preserves semantic of inline assembly's m restriction, as it asks for memory address of original variable, not some copy. The real question is: Is the difference observable? When I made the suggestion, I did so because I felt the answer was no. But this is not true if you capture the address to use later. Thus, the difference is observable, and I'll vote that we simply not support this case. Eric, what do you think? I agree here. Let's go with this patch right now and do anything else incrementally. Thanks! -eric http://reviews.llvm.org/D10476 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11462: [AArch64] Pass subtarget feature +reserve-x18
echristo accepted this revision. echristo added a comment. This revision is now accepted and ready to land. Fine with me either way, just means that if you want to turn it off it'll require some more changes. I don't think it's a problem though. http://reviews.llvm.org/D11462 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11462: [AArch64] Pass subtarget feature +reserve-x18
Do we accept the inverse option here? (If not, why not?) If so, this will
add it in places it isn't supposed to go.
-eric
On Thu, Jul 23, 2015, 8:07 AM Akira Hatanaka ahata...@gmail.com wrote:
ahatanak created this revision.
ahatanak added reviewers: echristo, dexonsmith.
ahatanak added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.
This patch changes clang driver to pass subtarget feature +reserve-x18
instead of passing backend option -aarch64-reserve-x18. This is needed
since backend options do not make it to the backend when doing LTO.
http://reviews.llvm.org/D11462
Files:
lib/Driver/Tools.cpp
test/Driver/aarch64-fixed-x18.c
Index: test/Driver/aarch64-fixed-x18.c
===
--- test/Driver/aarch64-fixed-x18.c
+++ test/Driver/aarch64-fixed-x18.c
@@ -1,4 +1,4 @@
// RUN: %clang -target aarch64-none-gnu -ffixed-x18 -### %s 2 %t
// RUN: FileCheck --check-prefix=CHECK-FIXED-X18 %t %s
-// CHECK-FIXED-X18: -backend-option -aarch64-reserve-x18
+// CHECK-FIXED-X18: -target-feature +reserve-x18
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -919,11 +919,6 @@
else
CmdArgs.push_back(-aarch64-global-merge=true);
}
-
- if (Args.hasArg(options::OPT_ffixed_x18)) {
-CmdArgs.push_back(-backend-option);
-CmdArgs.push_back(-aarch64-reserve-x18);
- }
}
// Get CPU and ABI names. They are not independent
@@ -1971,6 +1966,9 @@
else
Features.push_back(-crc);
}
+
+ if (Args.hasArg(options::OPT_ffixed_x18))
+Features.push_back(+reserve-x18);
}
static void getTargetFeatures(const Driver D, const llvm::Triple Triple,
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11462: [AArch64] Pass subtarget feature +reserve-x18
echristo added a subscriber: echristo. echristo added a comment. Do we accept the inverse option here? (If not, why not?) If so, this will add it in places it isn't supposed to go. -eric http://reviews.llvm.org/D11462 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11466: Correct x86_64 Android fp128 mangled name
echristo added inline comments. Comment at: test/CodeGen/long_double_fp128.cpp:1 @@ +1,2 @@ +// RUN: %clang_cc1 -triple x86_64-linux-android -emit-llvm -O -o - %s \ +// RUN:| FileCheck %s --check-prefix=A64 rnk wrote: I don't think these tests need optimizations (-O). If they do there's a different problem :) http://reviews.llvm.org/D11466 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11419: [X86, inlineasm] Implement analysis of v, k, Y2, Yk, Yz constraints
echristo added a comment. Can we hold off on this until you get backend support for the constraints in? -eric Repository: rL LLVM http://reviews.llvm.org/D11419 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11319: Pass subtarget feature +reserve-r9 instead of passing backend option -arm-reserve-r9
echristo added a comment. Question: Would it be better to just use reserve=NUM and parse that rather than the single +/- per register? Or is it just not worth it here? http://reviews.llvm.org/D11319 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11319: Pass subtarget feature +reserve-r9 instead of passing backend option -arm-reserve-r9
echristo accepted this revision. echristo added a comment. Sure, I'm willing to go with that. Thanks! -eric http://reviews.llvm.org/D11319 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11319: Pass subtarget feature +reserve-r9 instead of passing backend option -arm-reserve-r9
echristo added a comment. The only other use case I can think of is something like the -ffixed-reg= option. I remember there being some issues with trying that in the register allocator, but it might make sense. Thoughts? -eric http://reviews.llvm.org/D11319 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10536: [X86, inlineasm] Improve analysis of x, Y0, Yi, Ym, Yt, L, e, Z, s asm constraints
echristo accepted this revision. echristo added a comment. LGTM, thanks so much for the work here! -eric Repository: rL LLVM http://reviews.llvm.org/D10536 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11273: Fixed style issues pointed out by Justin Bogner.
echristo added a comment. LGTM. -eric http://reviews.llvm.org/D11273 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10536: [X86, inlineasm] Implement v, k, Y2, Yk, Yz constraints, improve analysis for x, Y*, L, e, Z, s
echristo added a comment. This will need documentation updates yes? Also backend support? -eric Repository: rL LLVM http://reviews.llvm.org/D10536 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10536: [X86, inlineasm] Implement v, k, Y2, Yk, Yz constraints, improve analysis for x, Y*, L, e, Z, s
echristo added a comment. I don't see a test for the 'k' support or a few other things either. Can you split this out a bit into the various parts for checking the existing constraints, and adding individual ones? -eric Repository: rL LLVM http://reviews.llvm.org/D10536 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241924 - Fix a couple of typos: specifc-specific.
Author: echristo
Date: Fri Jul 10 13:25:52 2015
New Revision: 241924
URL: http://llvm.org/viewvc/llvm-project?rev=241924view=rev
Log:
Fix a couple of typos: specifc-specific.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Sema/SemaExceptionSpec.cpp
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=241924r1=241923r2=241924view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Fri Jul 10 13:25:52 2015
@@ -1519,7 +1519,7 @@ public:
BuiltinVaListKind getBuiltinVaListKind() const override {
return TargetInfo::CharPtrBuiltinVaList;
}
- // PPC64 Linux-specifc ABI options.
+ // PPC64 Linux-specific ABI options.
bool setABI(const std::string Name) override {
if (Name == elfv1 || Name == elfv1-qpx || Name == elfv2) {
ABI = Name;
Modified: cfe/trunk/lib/Sema/SemaExceptionSpec.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExceptionSpec.cpp?rev=241924r1=241923r2=241924view=diff
==
--- cfe/trunk/lib/Sema/SemaExceptionSpec.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExceptionSpec.cpp Fri Jul 10 13:25:52 2015
@@ -397,7 +397,7 @@ bool Sema::CheckEquivalentExceptionSpec(
// - both are dynamic-exception-specifications that have the same set of
// adjusted types.
//
- // C++0x [except.spec]p12: An exception-specifcation is non-throwing if it is
+ // C++0x [except.spec]p12: An exception-specification is non-throwing if it
is
// of the form throw(), noexcept, or noexcept(constant-expression) where
the
// constant-expression yields true.
//
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11105: Changed Driver::getToolChain() to use Triple as the key parameter.
echristo accepted this revision. echristo added a comment. This revision is now accepted and ready to land. LGTM. Thanks for the work here! -eric http://reviews.llvm.org/D11105 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241925 - Refactor PPC ABI handling to accept and silently ignore -mabi=altivec.
Author: echristo
Date: Fri Jul 10 13:25:54 2015
New Revision: 241925
URL: http://llvm.org/viewvc/llvm-project?rev=241925view=rev
Log:
Refactor PPC ABI handling to accept and silently ignore -mabi=altivec.
All of the ABIs we support are altivec style anyhow and so the option
doesn't make much sense with the modern ABIs. We could make this a more
noisy ignore, but it would break builds for projects that just pass
it along by default because of historical reasons.
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/ppc-abi.c
Modified: cfe/trunk/lib/Driver/Tools.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=241925r1=241924r2=241925view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Jul 10 13:25:54 2015
@@ -1272,9 +1272,7 @@ void Clang::AddPPCTargetArgs(const ArgLi
ArgStringList CmdArgs) const {
// Select the ABI to use.
const char *ABIName = nullptr;
- if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ)) {
-ABIName = A-getValue();
- } else if (getToolChain().getTriple().isOSLinux())
+ if (getToolChain().getTriple().isOSLinux())
switch (getToolChain().getArch()) {
case llvm::Triple::ppc64: {
// When targeting a processor that supports QPX, or if QPX is
@@ -1299,6 +1297,13 @@ void Clang::AddPPCTargetArgs(const ArgLi
break;
}
+ if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ))
+// The ppc64 linux abis are all altivec abis by default. Accept and
ignore
+// the option if given as we don't have backend support for any targets
+// that don't use the altivec abi.
+if (StringRef(A-getValue()) != altivec)
+ ABIName = A-getValue();
+
if (ABIName) {
CmdArgs.push_back(-target-abi);
CmdArgs.push_back(ABIName);
Modified: cfe/trunk/test/Driver/ppc-abi.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ppc-abi.c?rev=241925r1=241924r2=241925view=diff
==
--- cfe/trunk/test/Driver/ppc-abi.c (original)
+++ cfe/trunk/test/Driver/ppc-abi.c Fri Jul 10 13:25:54 2015
@@ -21,6 +21,8 @@
// RUN: -mabi=elfv1 | FileCheck -check-prefix=CHECK-ELFv1 %s
// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 21 \
// RUN: -mabi=elfv2 | FileCheck -check-prefix=CHECK-ELFv2 %s
+// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o 21 \
+// RUN: -mabi=altivec | FileCheck -check-prefix=CHECK-ELFv2 %s
// CHECK-ELFv1: -target-abi elfv1
// CHECK-ELFv1-QPX: -target-abi elfv1-qpx
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241925 - Refactor PPC ABI handling to accept and silently ignore -mabi=altivec.
On Fri, Jul 10, 2015 at 11:42 AM Hal Finkel hfin...@anl.gov wrote:
- Original Message -
From: Eric Christopher echri...@gmail.com
To: cfe-commits@cs.uiuc.edu
Sent: Friday, July 10, 2015 1:25:54 PM
Subject: r241925 - Refactor PPC ABI handling to accept and silently
ignore-mabi=altivec.
Author: echristo
Date: Fri Jul 10 13:25:54 2015
New Revision: 241925
URL: http://llvm.org/viewvc/llvm-project?rev=241925view=rev
Log:
Refactor PPC ABI handling to accept and silently ignore
-mabi=altivec.
All of the ABIs we support are altivec style anyhow and so the option
doesn't make much sense with the modern ABIs. We could make this a
more
noisy ignore, but it would break builds for projects that just pass
it along by default because of historical reasons.
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/ppc-abi.c
Modified: cfe/trunk/lib/Driver/Tools.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=241925r1=241924r2=241925view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Jul 10 13:25:54 2015
@@ -1272,9 +1272,7 @@ void Clang::AddPPCTargetArgs(const ArgLi
ArgStringList CmdArgs) const {
// Select the ABI to use.
const char *ABIName = nullptr;
- if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ)) {
-ABIName = A-getValue();
- } else if (getToolChain().getTriple().isOSLinux())
+ if (getToolChain().getTriple().isOSLinux())
switch (getToolChain().getArch()) {
case llvm::Triple::ppc64: {
// When targeting a processor that supports QPX, or if QPX is
@@ -1299,6 +1297,13 @@ void Clang::AddPPCTargetArgs(const ArgLi
break;
}
+ if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ))
+// The ppc64 linux abis are all altivec abis by default.
Accept and ignore
+// the option if given as we don't have backend support for any
targets
+// that don't use the altivec abi.
I'm sorry, I should have warned you. This is not quite true. The QPX ABI
is not an altivec ABI, and we should do something slightly different in
that case. My preference is to produce an error, maybe something like this:
if (StringRef(A-getValue()) == altivec ABIName == elfv1-qpx)
error: The Altivec ABI is incompatible with QPX
Aha! Sure, I can do that.
Thanks!
-eric
Thanks again,
Hal
+if (StringRef(A-getValue()) != altivec)
+ ABIName = A-getValue();
+
if (ABIName) {
CmdArgs.push_back(-target-abi);
CmdArgs.push_back(ABIName);
Modified: cfe/trunk/test/Driver/ppc-abi.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ppc-abi.c?rev=241925r1=241924r2=241925view=diff
==
--- cfe/trunk/test/Driver/ppc-abi.c (original)
+++ cfe/trunk/test/Driver/ppc-abi.c Fri Jul 10 13:25:54 2015
@@ -21,6 +21,8 @@
// RUN: -mabi=elfv1 | FileCheck -check-prefix=CHECK-ELFv1 %s
// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o
21 \
// RUN: -mabi=elfv2 | FileCheck -check-prefix=CHECK-ELFv2 %s
+// RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -o %t.o
21 \
+// RUN: -mabi=altivec | FileCheck -check-prefix=CHECK-ELFv2 %s
// CHECK-ELFv1: -target-abi elfv1
// CHECK-ELFv1-QPX: -target-abi elfv1-qpx
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D9509: [cuda] Driver changes to build and stitch together host and device-side CUDA code.
echristo accepted this revision.
echristo added a comment.
This revision is now accepted and ready to land.
This is a good start. We'll probably want to do some more refactoring, but this
gets it in so we can look at it and make those decisions.
Make sure everything is formatted with clang-format, then LGTM.
-eric
Comment at: lib/Driver/Driver.cpp:822-823
@@ -820,3 +821,4 @@
static unsigned PrintActions1(const Compilation C, Action *A,
- std::mapAction*, unsigned Ids) {
+ std::mapAction *, unsigned Ids);
+
tra wrote:
echristo wrote:
Can you rearrange the code so that it doesn't need the forward declaration?
Nope. PrintActions1 and PrintActionList call each other recursively. At least
one of them must have forward declaration.
Bleh. OK.
Comment at: lib/Driver/ToolChains.cpp:3668-3670
@@ +3667,5 @@
+
+llvm::opt::DerivedArgList *
+CudaToolChain::TranslateArgs(const llvm::opt::DerivedArgList Args,
+const char *BoundArch) const {
+ DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
Formatting?
http://reviews.llvm.org/D9509
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11106: use-after-dtor cmd option
echristo added a subscriber: echristo.
echristo added a comment.
Couple of nits I noticed when looking.
-eric
Comment at: .arclint:1-8
@@ +1,8 @@
+{
+ linters: {
+cppcheck: {
+ type: cppcheck,
+ include: (\\.cpp$)
+}
+ }
+}
Probably don't want this.
Comment at: include/clang/Driver/Options.td:561-563
@@ -560,2 +560,5 @@
HelpTextDisable origins tracking in
MemorySanitizer;
+def fsanitize_memory_use_after_dtor : Flag[-],
fsanitize-memory-use-after-dtor,
+ Groupf_clang_Group, Flags[CC1Option],
+ HelpTextEnable use-after-destroy
detection in MemorySanitizer;
def fsanitize_address_field_padding : Joined[-],
fsanitize-address-field-padding=,
clang-format? also inverse option?
Comment at: lib/CodeGen/CGClass.cpp:1459
@@ +1458,3 @@
+
+ // insert memory-posioning instrumentation
+ if (CGM.getCodeGenOpts().SanitizeMemoryUseAfterDtor) {
Comments are complete sentences.
http://reviews.llvm.org/D11106
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10476: Additional fix for PR14269: Clang crashes when a bit field is used as inline assembler input / output with memory constraint
This seems to be a bit overconstrained versus what gcc accepts on the testcase:
dzur:~/tmp gcc -S baz.c
|
baz.c: In function ‘test16’:
|
baz.c:18:4: error: cannot take address of bit-field ‘field3’
|
: m (a.field3)); // expected-error {{reference to a non-addressable value
in asm input with a me\|
m
|
^
|
baz.c:28:4: error: address of global register variable ‘test16_baz’ requested
|
: m (test16_baz)); // expected-error {{reference to a non-addressable value
in asm input with a \|
m
|
^
|
baz.c:16:3: error: memory input 0 is not directly addressable
|
__asm__(movl $5, %0
|
^
|
baz.c:26:3: error: memory input 0 is not directly addressable
|
__asm__(movl $5, %0
|
^
|
also, the precision in error messages is nice. :)
-eric
http://reviews.llvm.org/D10476
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D9509: [cuda] Driver changes to build and stitch together host and device-side CUDA code.
Couple of inline comments, and I'm still not a huge fan of the
getTargetToolChain bits. It seems like we should be able to have a single
interface to getting a target toolchain that works for both cases. Maybe
compute the triple up front for use in the rest of the driver for the host?
Good lord cuda is terrible. :)
-eric
Comment at: include/clang/Driver/Driver.h:412-414
@@ -411,2 +411,5 @@
/// on-demand.
+ const ToolChain getTargetToolChain(const llvm::opt::ArgList Args,
+ const llvm::Triple Target) const;
+
const ToolChain getToolChain(const llvm::opt::ArgList Args,
The comments no longer match the code here.
Comment at: lib/Driver/Driver.cpp:822-823
@@ -820,3 +821,4 @@
static unsigned PrintActions1(const Compilation C, Action *A,
- std::mapAction*, unsigned Ids) {
+ std::mapAction *, unsigned Ids);
+
Can you rearrange the code so that it doesn't need the forward declaration?
http://reviews.llvm.org/D9509
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D9509: [cuda] Driver changes to build and stitch together host and device-side CUDA code.
On Tue, Jul 7, 2015 at 1:27 PM Artem Belevich t...@google.com wrote: In http://reviews.llvm.org/D9509#200597, @echristo wrote: Couple of inline comments, and I'm still not a huge fan of the getTargetToolChain bits. It seems like we should be able to have a single interface to getting a target toolchain that works for both cases. Maybe compute the triple up front for use in the rest of the driver for the host? Existing code commingles two independent things -- figuring out target triple value and retrieving corresponding ToolChain for a given Triple. My change just refactored out Triple-ToolChain mapping. Right. That's a good start for sure. Let's also see if we can refactor out BindArchAction to be a Triple (or stringref of triple) instead of passing DarwinArchName around and just use the triple. echristo wrote: Can you rearrange the code so that it doesn't need the forward declaration? Nope. PrintActions1 and PrintActionList call each other recursively. At least one of them must have forward declaration. Hrm. -eric ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241626 - Underscores in constructor arguments are so passe.
Author: echristo
Date: Tue Jul 7 16:00:42 2015
New Revision: 241626
URL: http://llvm.org/viewvc/llvm-project?rev=241626view=rev
Log:
Underscores in constructor arguments are so passe.
Modified:
cfe/trunk/include/clang/Driver/Action.h
Modified: cfe/trunk/include/clang/Driver/Action.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Action.h?rev=241626r1=241625r2=241626view=diff
==
--- cfe/trunk/include/clang/Driver/Action.h (original)
+++ cfe/trunk/include/clang/Driver/Action.h Tue Jul 7 16:00:42 2015
@@ -71,16 +71,16 @@ private:
unsigned OwnsInputs : 1;
protected:
- Action(ActionClass _Kind, types::ID _Type)
-: Kind(_Kind), Type(_Type), OwnsInputs(true) {}
- Action(ActionClass _Kind, std::unique_ptrAction Input, types::ID _Type)
- : Kind(_Kind), Type(_Type), Inputs(1, Input.release()), OwnsInputs(true)
{
+ Action(ActionClass Kind, types::ID Type)
+: Kind(Kind), Type(Type), OwnsInputs(true) {}
+ Action(ActionClass Kind, std::unique_ptrAction Input, types::ID Type)
+ : Kind(Kind), Type(Type), Inputs(1, Input.release()), OwnsInputs(true) {
}
- Action(ActionClass _Kind, std::unique_ptrAction Input)
- : Kind(_Kind), Type(Input-getType()), Inputs(1, Input.release()),
+ Action(ActionClass Kind, std::unique_ptrAction Input)
+ : Kind(Kind), Type(Input-getType()), Inputs(1, Input.release()),
OwnsInputs(true) {}
- Action(ActionClass _Kind, const ActionList _Inputs, types::ID _Type)
-: Kind(_Kind), Type(_Type), Inputs(_Inputs), OwnsInputs(true) {}
+ Action(ActionClass Kind, const ActionList Inputs, types::ID Type)
+: Kind(Kind), Type(Type), Inputs(Inputs), OwnsInputs(true) {}
public:
virtual ~Action();
@@ -108,7 +108,7 @@ class InputAction : public Action {
const llvm::opt::Arg Input;
public:
- InputAction(const llvm::opt::Arg _Input, types::ID _Type);
+ InputAction(const llvm::opt::Arg Input, types::ID Type);
const llvm::opt::Arg getInputArg() const { return Input; }
@@ -124,7 +124,7 @@ class BindArchAction : public Action {
const char *ArchName;
public:
- BindArchAction(std::unique_ptrAction Input, const char *_ArchName);
+ BindArchAction(std::unique_ptrAction Input, const char *ArchName);
const char *getArchName() const { return ArchName; }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241524 - Add some basic documentation for the __attribute__((target())) support.
Author: echristo
Date: Mon Jul 6 18:51:56 2015
New Revision: 241524
URL: http://llvm.org/viewvc/llvm-project?rev=241524view=rev
Log:
Add some basic documentation for the __attribute__((target())) support.
Describes the general syntax of how it's used with the unfortunate
usage of subtarget features and some examples from the x86 port
to help users.
Modified:
cfe/trunk/include/clang/Basic/AttrDocs.td
Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=241524r1=241523r2=241524view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Mon Jul 6 18:51:56 2015
@@ -678,6 +678,25 @@ The semantics are as follows:
}];
}
+def TargetDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Clang supports the GNU style ``__attribute__((target(OPTIONS)))`` attribute.
+This attribute may be attached to a function definition and instructs
+the backend to use different code generation options than were passed on the
+command line.
+
+The current set of options correspond to the existing subtarget features for
+the target with or without a -mno- in front corresponding to the absence
+of the feature, as well as ``arch=CPU`` which will change the default CPU
+for the function.
+
+Example subtarget features from the x86 backend include: mmx, sse,
sse4.2,
+avx, xop and largely correspond to the machine specific options handled by
+the front end.
+}];
+}
+
def DocCatAMDGPURegisterAttributes :
DocumentationCategoryAMD GPU Register Attributes {
let Content = [{
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241526 - Update target attribute support for post-commit feedback.
Author: echristo
Date: Mon Jul 6 18:52:01 2015
New Revision: 241526
URL: http://llvm.org/viewvc/llvm-project?rev=241526view=rev
Log:
Update target attribute support for post-commit feedback.
Use const auto rather than duplicating the type name and fix the
error message when the attribute is applied to an incorrect entity.
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/CodeGen/CGCall.cpp
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=241526r1=241525r2=241526view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Jul 6 18:52:01 2015
@@ -1277,7 +1277,7 @@ def Target : InheritableAttr {
let Spellings = [GCCtarget];
let Args = [StringArgumentfeatures];
let Subjects =
- SubjectList[Function], ErrorDiag, ExpectedFunctionMethodOrClass;
+ SubjectList[Function], ErrorDiag, ExpectedFunction;
let Documentation = [Undocumented];
}
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241526r1=241525r2=241526view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Jul 6 18:52:01 2015
@@ -1506,7 +1506,7 @@ void CodeGenModule::ConstructAttributeLi
const FunctionDecl *FD = dyn_cast_or_nullFunctionDecl(TargetDecl);
if (FD) {
- if (const TargetAttr *TD = FD-getAttrTargetAttr()) {
+ if (const auto *TD = FD-getAttrTargetAttr()) {
StringRef FeaturesStr = TD-getFeatures();
SmallVectorStringRef, 1 AttrFeatures;
FeaturesStr.split(AttrFeatures, ,);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241525 - Handle arbitrary whitespace in the target attribute support.
Author: echristo
Date: Mon Jul 6 18:51:59 2015
New Revision: 241525
URL: http://llvm.org/viewvc/llvm-project?rev=241525view=rev
Log:
Handle arbitrary whitespace in the target attribute support.
This allows us to deal a bit more gracefully with inclusions done
by macros, token pasting, or just code layout/formatting.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/attr-target.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241525r1=241524r2=241525view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Jul 6 18:51:59 2015
@@ -1514,9 +1514,13 @@ void CodeGenModule::ConstructAttributeLi
// Grab the various features and prepend a + to turn on the feature
to
// the backend and add them to our existing set of features.
for (auto Feature : AttrFeatures) {
+ // Go ahead and trim whitespace rather than either erroring or
+ // accepting it weirdly.
+ Feature = Feature.trim();
+
// While we're here iterating check for a different target cpu.
if (Feature.startswith(arch=))
-TargetCPU = Feature.split(=).second;
+TargetCPU = Feature.split(=).second.trim();
else if (Feature.startswith(tune=))
// We don't support cpu tuning this way currently.
;
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241525r1=241524r2=241525view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Mon Jul 6 18:51:59 2015
@@ -13,6 +13,8 @@ int __attribute__((target(sse4))) pand
int bar(int a) { return baz(a) + foo(a); }
+int __attribute__((target(avx, sse4.2, arch= ivybridge)))
qux(int a) { return 4; }
+
// Check that we emit the additional subtarget and cpu features for foo and
not for baz or bar.
// CHECK: baz{{.*}} #0
// CHECK: foo{{.*}} #1
@@ -22,6 +24,7 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: koala{{.*}} #0
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
+// CHECK: qux{{.*}} #1
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+avx,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3
// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=+sse,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241529 - Remember to mark the target attribute as documented and clean up the
Author: echristo
Date: Mon Jul 6 19:01:55 2015
New Revision: 241529
URL: http://llvm.org/viewvc/llvm-project?rev=241529view=rev
Log:
Remember to mark the target attribute as documented and clean up the
Subjects line to avoid redundancy.
Modified:
cfe/trunk/include/clang/Basic/Attr.td
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=241529r1=241528r2=241529view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Jul 6 19:01:55 2015
@@ -1276,9 +1276,8 @@ def Pascal : InheritableAttr {
def Target : InheritableAttr {
let Spellings = [GCCtarget];
let Args = [StringArgumentfeatures];
- let Subjects =
- SubjectList[Function], ErrorDiag, ExpectedFunction;
- let Documentation = [Undocumented];
+ let Subjects = SubjectList[Function], ErrorDiag;
+ let Documentation = [TargetDocs];
}
def TransparentUnion : InheritableAttr {
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r239579 - Add support for the the target attribute.
You get a single email reply for the two of you. :)
Fixed the requests with the following:
dzur:~/sources/llvm/tools/clang git svn dcommit
Committing to https://llvm.org/svn/llvm-project/cfe/trunk ...
M include/clang/Basic/AttrDocs.td
Committed r241524
M include/clang/Basic/AttrDocs.td
r241524 = 958aa2fcd7ce159211cb76409d97efdbef1d1524
(refs/remotes/origin/master)
M lib/CodeGen/CGCall.cpp
M test/CodeGen/attr-target.c
Committed r241525
M test/CodeGen/attr-target.c
M lib/CodeGen/CGCall.cpp
r241525 = 3b4cd0da85bd32acd27e4459f7e7e9f4658ce289
(refs/remotes/origin/master)
M include/clang/Basic/Attr.td
M lib/CodeGen/CGCall.cpp
Committed r241526
M lib/CodeGen/CGCall.cpp
M include/clang/Basic/Attr.td
r241526 = 7bf902c36d7cbed7343d99c1c6737672d00fd462
(refs/remotes/origin/master)
A few comments:
a) Documentation - it's not good, but you're right, some is better than
nothing. Full documentation of the various backend features sounds like
something that might be handled in a different way, but I'm still thinking
about it. Until then though, some documentation :)
+ SubjectList[Function], ErrorDiag,
ExpectedFunctionMethodOrClass;
The diagnostic for this does not match the subject list, and I don't
understand why. It only applies to functions, but the diagnostic will
tell the user it can apply to classes and Obj-C methods, which is not
good.
Uh, right. Oops and thanks.
+if (FD) {
+ if (const TargetAttr *TD = FD-getAttrTargetAttr()) {
Better to use const auto here instead of spelling the type twice.
Sure. I'm more conservative with my use of auto, but I'm here anyhow.
+StringRef FeaturesStr = TD-getFeatures();
+SmallVectorStringRef, 1 AttrFeatures;
+FeaturesStr.split(AttrFeatures, ,);
Does the backend handle spaces and tabs sensibly? eg)
[[gnu::target(foo, bar, baz)]]?
Nope. Neither did gcc. I've fixed it for us and it handles some weird
whitespace. I don't handle arbitrary whitespace for arch= and tune= but if
you think it's something someone could do I could start regexp matching
them.
+static void handleTargetAttr(Sema S, Decl *D, const AttributeList
Attr) {
+ // TODO: Validation should use a backend target library that specifies
+ // the allowable subtarget features and cpus. We could use something
like a
+ // TargetCodeGenInfo hook here to do validation.
Is there a rough timeline as to when this TODO will be fixed? I'm
worried about attribute with weird, silent misbehavior if someone has
a simple typo.
Well, the backend would complain if it couldn't parse the attribute so I'm
less worried about that - that said, I do plan on adding some verification
of the backend features I know about based on the other work I did for the
__builtin_cpu_supports work.
This could be written without the extra declarations, but it's not
that big of a deal either.
Enh, I went ahead and left this. It feels more comforting to me :)
Thanks a lot for the review. Very appreciated :)
-eric
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241526 - Update target attribute support for post-commit feedback.
On Mon, Jul 6, 2015 at 4:57 PM Aaron Ballman aa...@aaronballman.com wrote:
On Mon, Jul 6, 2015 at 7:52 PM, Eric Christopher echri...@gmail.com
wrote:
Author: echristo
Date: Mon Jul 6 18:52:01 2015
New Revision: 241526
URL: http://llvm.org/viewvc/llvm-project?rev=241526view=rev
Log:
Update target attribute support for post-commit feedback.
Use const auto rather than duplicating the type name and fix the
error message when the attribute is applied to an incorrect entity.
Thank you for this (one comment below)!
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/CodeGen/CGCall.cpp
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=241526r1=241525r2=241526view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Jul 6 18:52:01 2015
@@ -1277,7 +1277,7 @@ def Target : InheritableAttr {
let Spellings = [GCCtarget];
let Args = [StringArgumentfeatures];
let Subjects =
- SubjectList[Function], ErrorDiag,
ExpectedFunctionMethodOrClass;
+ SubjectList[Function], ErrorDiag, ExpectedFunction;
You can actually elide the ExpectedFunction part as well. The tablegen
smarts handle the easy cases for you.
Hey, cool, thanks :)
Done thusly:
dzur:~/sources/llvm/tools/clang git svn dcommit
Committing to https://llvm.org/svn/llvm-project/cfe/trunk ...
M include/clang/Basic/Attr.td
Committed r241529
-eric
~Aaron
let Documentation = [Undocumented];
}
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241526r1=241525r2=241526view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Jul 6 18:52:01 2015
@@ -1506,7 +1506,7 @@ void CodeGenModule::ConstructAttributeLi
const FunctionDecl *FD = dyn_cast_or_nullFunctionDecl(TargetDecl);
if (FD) {
- if (const TargetAttr *TD = FD-getAttrTargetAttr()) {
+ if (const auto *TD = FD-getAttrTargetAttr()) {
StringRef FeaturesStr = TD-getFeatures();
SmallVectorStringRef, 1 AttrFeatures;
FeaturesStr.split(AttrFeatures, ,);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241524 - Add some basic documentation for the __attribute__((target())) support.
On Mon, Jul 6, 2015 at 4:55 PM Aaron Ballman aa...@aaronballman.com wrote:
On Mon, Jul 6, 2015 at 7:51 PM, Eric Christopher echri...@gmail.com
wrote:
Author: echristo
Date: Mon Jul 6 18:51:56 2015
New Revision: 241524
URL: http://llvm.org/viewvc/llvm-project?rev=241524view=rev
Log:
Add some basic documentation for the __attribute__((target())) support.
Describes the general syntax of how it's used with the unfortunate
usage of subtarget features and some examples from the x86 port
to help users.
Modified:
cfe/trunk/include/clang/Basic/AttrDocs.td
Did you forget to change the Undocument in Attr.td for the TargetAttr
object?
Why yes, yes I did.
dzur:~/sources/llvm/tools/clang git svn dcommit
Committing to https://llvm.org/svn/llvm-project/cfe/trunk ...
M include/clang/Basic/Attr.td
Committed r241529
Thanks!
-eric
~Aaron
Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=241524r1=241523r2=241524view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Mon Jul 6 18:51:56 2015
@@ -678,6 +678,25 @@ The semantics are as follows:
}];
}
+def TargetDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Clang supports the GNU style ``__attribute__((target(OPTIONS)))``
attribute.
+This attribute may be attached to a function definition and instructs
+the backend to use different code generation options than were passed
on the
+command line.
+
+The current set of options correspond to the existing subtarget
features for
+the target with or without a -mno- in front corresponding to the
absence
+of the feature, as well as ``arch=CPU`` which will change the default
CPU
+for the function.
+
+Example subtarget features from the x86 backend include: mmx,
sse, sse4.2,
+avx, xop and largely correspond to the machine specific options
handled by
+the front end.
+}];
+}
+
def DocCatAMDGPURegisterAttributes :
DocumentationCategoryAMD GPU Register Attributes {
let Content = [{
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D10875: Add missing builtins to altivec.h for ABI compliance (vol. 2)
echristo accepted this revision. This revision is now accepted and ready to land. LGTM thanks! -eric Repository: rL LLVM http://reviews.llvm.org/D10875 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D9414: [ARM] Save option arm-long-calls to the IR as a function attribute
echristo accepted this revision.
This revision is now accepted and ready to land.
Couple of inline comments, go ahead and commit when you've resolved them.
Thanks!
-eric
Comment at: lib/Driver/Tools.cpp:715-716
@@ +714,4 @@
+ Features.push_back(+long-calls);
+ } else if (KernelOrKext (!Triple.isiOS() || Triple.isOSVersionLT(6))) {
+ Features.push_back(+long-calls);
+ }
Can you add a plain english comment above this explaining what we're supposed
to be checking here? :)
Comment at: test/CodeGen/arm-long-calls.c:3
@@ +2,3 @@
+// RUN: %clang_cc1 -triple thumbv7-apple-ios5 -emit-llvm -o - %s | FileCheck
-check-prefix=NOLONGCALL %s
+
+// LONGCALL: attributes #0 = { {{.*}} target-features=+long-calls
Test for -mno-long-calls?
http://reviews.llvm.org/D9414
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241134 - Use a stable sort to guarantee target feature ordering in the IR
Looks like Ben nicely cleaned up a few things for me here:
Author: Benjamin Kramer benny@googlemail.com
Date: Thu Jul 2 21:02:39 2015 +
[CodeGen] Use llvm::join to simplify string joining.
While there replace stable_sort of std::string with just sort, stability
is not necessary for simple value types. No functional change
intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241299
91177308-0d34-0410-b5e6-96231b3b80d8
Thanks Ben!
-eric
On Sat, Jul 4, 2015 at 12:15 PM Eric Christopher echri...@gmail.com wrote:
Ah, yeah, probably. I'll get that.
Thanks!
-eric
On Thu, Jul 2, 2015 at 5:54 AM Rafael Espíndola
rafael.espind...@gmail.com wrote:
Why stable_sort? Since it is sorting std::string elements just a plain
sort should work, no?
On 30 June 2015 at 21:07, Eric Christopher echri...@gmail.com wrote:
Author: echristo
Date: Tue Jun 30 20:07:12 2015
New Revision: 241134
URL: http://llvm.org/viewvc/llvm-project?rev=241134view=rev
Log:
Use a stable sort to guarantee target feature ordering in the IR
in order to make testing somewhat more feasible. Has the advantage
of making it easier to find target features as well.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/arm-target-features.c
cfe/trunk/test/CodeGen/attr-target.c
cfe/trunk/test/CodeGen/function-target-features.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Jun 30 20:07:12 2015
@@ -1544,6 +1544,7 @@ void CodeGenModule::ConstructAttributeLi
if (TargetCPU != )
FuncAttrs.addAttribute(target-cpu, TargetCPU);
if (!Features.empty()) {
+ std::stable_sort(Features.begin(), Features.end());
std::stringstream TargetFeatures;
std::copy(Features.begin(), Features.end(),
std::ostream_iteratorstd::string(TargetFeatures,
,));
Modified: cfe/trunk/test/CodeGen/arm-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-target-features.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/arm-target-features.c (original)
+++ cfe/trunk/test/CodeGen/arm-target-features.c Tue Jun 30 20:07:12
2015
@@ -6,7 +6,7 @@
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu
cortex-a5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
-// CHECK-VFP4: target-features=+vfp4,+neon
+// CHECK-VFP4: target-features=+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu
cortex-a7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
@@ -15,14 +15,14 @@
// RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu
cortex-a17 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
-// CHECK-VFP4-DIV: target-features=+vfp4,+neon,+hwdiv,+hwdiv-arm
+// CHECK-VFP4-DIV: target-features=+hwdiv,+hwdiv-arm,+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu
cortex-a57 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu
cortex-a72 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
-// CHECK-BASIC-V8:
target-features=+neon,+fp-armv8,+hwdiv,+crypto,+crc,+hwdiv-arm
+// CHECK-BASIC-V8:
target-features=+crc,+crypto,+fp-armv8,+hwdiv,+hwdiv-arm,+neon
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r5
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-DIV
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Tue Jun 30 20:07:12 2015
@@ -23,6 +23,6 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64
target-features=+sse,+sse2
-// CHECK
Re: r241134 - Use a stable sort to guarantee target feature ordering in the IR
Ah, yeah, probably. I'll get that.
Thanks!
-eric
On Thu, Jul 2, 2015 at 5:54 AM Rafael Espíndola rafael.espind...@gmail.com
wrote:
Why stable_sort? Since it is sorting std::string elements just a plain
sort should work, no?
On 30 June 2015 at 21:07, Eric Christopher echri...@gmail.com wrote:
Author: echristo
Date: Tue Jun 30 20:07:12 2015
New Revision: 241134
URL: http://llvm.org/viewvc/llvm-project?rev=241134view=rev
Log:
Use a stable sort to guarantee target feature ordering in the IR
in order to make testing somewhat more feasible. Has the advantage
of making it easier to find target features as well.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/arm-target-features.c
cfe/trunk/test/CodeGen/attr-target.c
cfe/trunk/test/CodeGen/function-target-features.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Jun 30 20:07:12 2015
@@ -1544,6 +1544,7 @@ void CodeGenModule::ConstructAttributeLi
if (TargetCPU != )
FuncAttrs.addAttribute(target-cpu, TargetCPU);
if (!Features.empty()) {
+ std::stable_sort(Features.begin(), Features.end());
std::stringstream TargetFeatures;
std::copy(Features.begin(), Features.end(),
std::ostream_iteratorstd::string(TargetFeatures,
,));
Modified: cfe/trunk/test/CodeGen/arm-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-target-features.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/arm-target-features.c (original)
+++ cfe/trunk/test/CodeGen/arm-target-features.c Tue Jun 30 20:07:12 2015
@@ -6,7 +6,7 @@
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu
cortex-a5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
-// CHECK-VFP4: target-features=+vfp4,+neon
+// CHECK-VFP4: target-features=+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu
cortex-a7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
@@ -15,14 +15,14 @@
// RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
-// CHECK-VFP4-DIV: target-features=+vfp4,+neon,+hwdiv,+hwdiv-arm
+// CHECK-VFP4-DIV: target-features=+hwdiv,+hwdiv-arm,+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu
cortex-a57 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu
cortex-a72 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
-// CHECK-BASIC-V8:
target-features=+neon,+fp-armv8,+hwdiv,+crypto,+crc,+hwdiv-arm
+// CHECK-BASIC-V8:
target-features=+crc,+crypto,+fp-armv8,+hwdiv,+hwdiv-arm,+neon
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r5
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-DIV
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Tue Jun 30 20:07:12 2015
@@ -23,6 +23,6 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64
target-features=+sse,+sse2
-// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse4.2,+ssse3,+sse3,+sse,+sse2,+sse4.1,+avx
-// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=-sse4a,-sse3,-avx2,-avx512bw,-avx512er,-avx512dq,-avx512pf,-fma4,-avx512vl,+sse,-pclmul,-avx512cd,-avx,-f16c,-ssse3,-avx512f,-fma,-xop,-aes,-sha,-sse2,-sse4.1,-sse4.2
-// CHECK: #3 = {{.*}}target-cpu=x86-64
target-features=+ssse3,+sse3,+sse,+sse2,+sse4.1,+sse4.2
+// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+avx,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3
+// CHECK: #2 = {{.*}}target-cpu=x86-64
Re: [PATCH] [ARM] Save option arm-long-calls to the IR as a function attribute
Hi Akira, I'm not sure how we want to do calling convention type things. I don't know that we want it as a generic attribute on the function or as a subtarget feature. What are your thoughts here? -eric http://reviews.llvm.org/D9414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] OpenCL: Add new types for OpenCL 2.0
Ah. You should send it to the lldb list. On Thu, Jul 2, 2015, 12:56 AM Pedro Ferreira arkang...@gmail.com wrote: The one I had attached on the very first mail :) Re-attaching just in case it got lost. I was not able to test it - I meant only to add switch cases to silence build warnings. On Wed, 1 Jul 2015 at 22:57 Eric Christopher echri...@gmail.com wrote: What lldb patch? -eric On Tue, Jun 30, 2015 at 3:07 AM Pedro Ferreira arkang...@gmail.com wrote: Ping. Any further comments on this one? On Wed, 24 Jun 2015 at 10:43 Pedro Ferreira arkang...@gmail.com wrote: Would help to actually attach the thing. Is the patch to lldb good? It's not really important for me - I just didn't want to add warnings to the lldb build. (this time adding cfe commits) On Fri, 19 Jun 2015 at 08:23 Pedro Ferreira arkang...@gmail.com wrote: Attached the patch after svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i On the file you mentioned (Type.h), further up there was already a line with over 80 characters - the limit was exceeded by the comment, so I figured that comments were an exemption. FWIW, the line is bool isObjCIndependentClassType() const; // __attribute__((objc_independent_class)), which is 91 characters long. On Fri, 19 Jun 2015 at 04:32 Richard Smith rich...@metafoo.co.uk wrote: On Thu, Jun 18, 2015 at 5:41 PM, Eric Christopher echri...@gmail.com wrote: Please run clang-format on your patch. You still have lines over 80-columns for example. + bool isImage2dDepthT() const; // Opencl image_2d_depth_t + bool isImage2dArrayDepthT() const;// Opencl image_2d_array_depth_t + bool isImage2dMSAAT() const; // Opencl image_2d_msaa_t + bool isImage2dArrayMSAAT() const; // Opencl image_2d_array_msaa_t + bool isImage2dMSAATDepth() const; // Opencl image_2d_msaa_depth_t + bool isImage2dArrayMSAATDepth() const;// Opencl image_2d_array_msaa_depth_t Here's an example of an over-80-columns line. Please also fix the capitalization to OpenCL here to match the surrounding code. Thanks. -eric On Wed, Jun 17, 2015, 7:38 AM Pedro Ferreira arkang...@gmail.com wrote: Updated from head SVN - no conflicts. Still runs without failures. On Wed, 17 Jun 2015 at 15:08 Pedro Ferreira arkang...@gmail.com wrote: Sorry, that was my bad. I forgot to set my editor back to llvm indentation settings and it inserted tabs instead of spaces. Line 1000 of SemaTypes is 79 characters long, which is the largest (longest) line in the patch. It is the same length of line 981 from where I copy-pasted the code (by your suggestion). Grep claims the attached patch has no tabs now :) On Wed, 17 Jun 2015 at 14:47 Anastasia Stulova anastasia.stul...@arm.com wrote: I think there are still lines that are too long (especially in SemaType.cpp). Have you run clang-format on your changes? Otherwise, no further comments from my side. Anastasia *From:* Pedro Ferreira [mailto:arkang...@gmail.com] *Sent:* 15 June 2015 09:16 *To:* Eric Christopher; Anastasia Stulova; cfe-commits@cs.uiuc.edu *Subject:* Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 There were a couple lines with 80 columns, and this new patch version fixes them. On Fri, 12 Jun 2015 at 21:03 Eric Christopher echri...@gmail.com wrote: Drive by review here. I was making sure there was debug info support for the bits, thanks for adding it though I'm not seeing any tests ;) I'm pretty sure you have some 80-column violations and other formatting things, could you clang-format your patch? Thanks! -eric On Fri, Jun 12, 2015 at 4:20 AM Pedro Ferreira arkang...@gmail.com wrote: Awesome, thanks for the tips. Updated version attached. Pedro On Thu, 11 Jun 2015 at 19:23 Anastasia Stulova anastasia.stul...@arm.com wrote: CodeGen tests looks good! Regarding the extension, could you diagnose it during the type checking instead. That way it will be cover all cases. You can look at the CL2.0 atomic type implementation in SemaType.cpp ConvertDeclSpecToType. Also please reuse the same error err_type_requires_extension instead of adding the new one. Please, add Sema test demonstating the error handling works correctly. Thanks, Anastasia From: Pedro Ferreira [arkang...@gmail.com] Sent: Thursday, June 11, 2015 12:50 PM To: Anastasia Stulova; cfe-commits@cs.uiuc.edu Subject: Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 Ok, found out the right place to diagnose the extension and added the tests. I am not particularly convinced that was the best way to do it; comments welcome. Pedro On Thu, 11 Jun 2015 at 11:43 Pedro Ferreira arkang...@gmail.com mailto:arkang...@gmail.com wrote: Actually, I spoke too soon - I found a test with -cl-std=CL2.0. I missed that. On Thu, 11 Jun 2015 at 11:40 Pedro Ferreira
Re: [PATCH] Add missing builtins to altivec.h for ABI compliance (vol. 2)
Hi Nemanja,
Few inline comments then this looks good to me. Note that this isn't perfectly
compatible with the gcc version because of stricter types in things like
vec_vsx_ld/st, but I think that's ok here.
The inline comments generally happen quite a few times, but I've only
highlighted a single one in general.
Thanks!
-eric
REPOSITORY
rL LLVM
Comment at: lib/CodeGen/CGBuiltin.cpp:6565-6566
@@ +6564,4 @@
+ case PPC::BI__builtin_vsx_xvsqrtsp:
+ case PPC::BI__builtin_vsx_xvsqrtdp:
+ {
+llvm::Type *ResultType = ConvertType(E-getType());
Formatting?
Comment at: lib/Headers/altivec.h:5338
@@ -5205,3 +5337,3 @@
-static __vector float __attribute__((__always_inline__))
+static vector float __attribute__((__always_inline__))
vec_vrsqrtefp(vector float __a) {
This change seems unrelated, make it separately?
Comment at: lib/Headers/altivec.h:11208
@@ -11024,3 +11207,3 @@
-static int __attribute__((__always_inline__))
+static int __ATTRS_o_ai
vec_all_nge(vector float __a, vector float __b) {
Make all of these changes separately?
Comment at: test/CodeGen/builtins-ppc-vsx.c:36
@@ -35,3 +35,3 @@
// CHECK: and 2 x i64
-// CHECK: bitcast 2 x i64 %{{[0-9]*}} to 2 x double
+// CHECK: bitcast 2 x i64 %{{[0-9]+}} to 2 x double
Seems like something that should be made separately?
http://reviews.llvm.org/D10875
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] OpenCL: Add new types for OpenCL 2.0
What lldb patch? -eric On Tue, Jun 30, 2015 at 3:07 AM Pedro Ferreira arkang...@gmail.com wrote: Ping. Any further comments on this one? On Wed, 24 Jun 2015 at 10:43 Pedro Ferreira arkang...@gmail.com wrote: Would help to actually attach the thing. Is the patch to lldb good? It's not really important for me - I just didn't want to add warnings to the lldb build. (this time adding cfe commits) On Fri, 19 Jun 2015 at 08:23 Pedro Ferreira arkang...@gmail.com wrote: Attached the patch after svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i On the file you mentioned (Type.h), further up there was already a line with over 80 characters - the limit was exceeded by the comment, so I figured that comments were an exemption. FWIW, the line is bool isObjCIndependentClassType() const; // __attribute__((objc_independent_class)), which is 91 characters long. On Fri, 19 Jun 2015 at 04:32 Richard Smith rich...@metafoo.co.uk wrote: On Thu, Jun 18, 2015 at 5:41 PM, Eric Christopher echri...@gmail.com wrote: Please run clang-format on your patch. You still have lines over 80-columns for example. + bool isImage2dDepthT() const; // Opencl image_2d_depth_t + bool isImage2dArrayDepthT() const;// Opencl image_2d_array_depth_t + bool isImage2dMSAAT() const; // Opencl image_2d_msaa_t + bool isImage2dArrayMSAAT() const; // Opencl image_2d_array_msaa_t + bool isImage2dMSAATDepth() const; // Opencl image_2d_msaa_depth_t + bool isImage2dArrayMSAATDepth() const;// Opencl image_2d_array_msaa_depth_t Here's an example of an over-80-columns line. Please also fix the capitalization to OpenCL here to match the surrounding code. Thanks. -eric On Wed, Jun 17, 2015, 7:38 AM Pedro Ferreira arkang...@gmail.com wrote: Updated from head SVN - no conflicts. Still runs without failures. On Wed, 17 Jun 2015 at 15:08 Pedro Ferreira arkang...@gmail.com wrote: Sorry, that was my bad. I forgot to set my editor back to llvm indentation settings and it inserted tabs instead of spaces. Line 1000 of SemaTypes is 79 characters long, which is the largest (longest) line in the patch. It is the same length of line 981 from where I copy-pasted the code (by your suggestion). Grep claims the attached patch has no tabs now :) On Wed, 17 Jun 2015 at 14:47 Anastasia Stulova anastasia.stul...@arm.com wrote: I think there are still lines that are too long (especially in SemaType.cpp). Have you run clang-format on your changes? Otherwise, no further comments from my side. Anastasia *From:* Pedro Ferreira [mailto:arkang...@gmail.com] *Sent:* 15 June 2015 09:16 *To:* Eric Christopher; Anastasia Stulova; cfe-commits@cs.uiuc.edu *Subject:* Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 There were a couple lines with 80 columns, and this new patch version fixes them. On Fri, 12 Jun 2015 at 21:03 Eric Christopher echri...@gmail.com wrote: Drive by review here. I was making sure there was debug info support for the bits, thanks for adding it though I'm not seeing any tests ;) I'm pretty sure you have some 80-column violations and other formatting things, could you clang-format your patch? Thanks! -eric On Fri, Jun 12, 2015 at 4:20 AM Pedro Ferreira arkang...@gmail.com wrote: Awesome, thanks for the tips. Updated version attached. Pedro On Thu, 11 Jun 2015 at 19:23 Anastasia Stulova anastasia.stul...@arm.com wrote: CodeGen tests looks good! Regarding the extension, could you diagnose it during the type checking instead. That way it will be cover all cases. You can look at the CL2.0 atomic type implementation in SemaType.cpp ConvertDeclSpecToType. Also please reuse the same error err_type_requires_extension instead of adding the new one. Please, add Sema test demonstating the error handling works correctly. Thanks, Anastasia From: Pedro Ferreira [arkang...@gmail.com] Sent: Thursday, June 11, 2015 12:50 PM To: Anastasia Stulova; cfe-commits@cs.uiuc.edu Subject: Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 Ok, found out the right place to diagnose the extension and added the tests. I am not particularly convinced that was the best way to do it; comments welcome. Pedro On Thu, 11 Jun 2015 at 11:43 Pedro Ferreira arkang...@gmail.com mailto:arkang...@gmail.com wrote: Actually, I spoke too soon - I found a test with -cl-std=CL2.0. I missed that. On Thu, 11 Jun 2015 at 11:40 Pedro Ferreira arkang...@gmail.com mailto:arkang...@gmail.com wrote: The codegen test would imply adding a -cl-std=2.0 option to Clang, which it currently does not have. This is because the types should only be recognised if the CL 2.0 standard is explicitly asked for (the default is to operate on 1.2 mode). Adding that option is a peripheral issue. I've added the types on the header
Re: [PATCH] Attach attribute trap-func-name to IR function
You'll want to also test a trap inside of a ctor/dtor, global constructor (if you can), etc. The general change looks fine though. Thanks! -eric http://reviews.llvm.org/D10831 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute arm-restrict-it instead of passing arm-restrict-it as a backend-option
I like this much more. Can we get a CodeGen check for this? LGTM otherwise. Thanks! -eric http://reviews.llvm.org/D10414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241130 - Fix sse4 for target attribute feature additions.
Author: echristo
Date: Tue Jun 30 19:08:32 2015
New Revision: 241130
URL: http://llvm.org/viewvc/llvm-project?rev=241130view=rev
Log:
Fix sse4 for target attribute feature additions.
This reinstates part of the hack removed in r233223, by special
casing sse4 as part of the feature additions. The notable change
here is that we consider it only as part of setting the SSE level
and not as part of the actual target features set which handles
setting the rest of the masks.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/CodeGen/attr-target.c
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=241130r1=241129r2=241130view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Jun 30 19:08:32 2015
@@ -2728,7 +2728,11 @@ void X86TargetInfo::setXOPLevel(llvm::St
void X86TargetInfo::setFeatureEnabledImpl(llvm::StringMapbool Features,
StringRef Name, bool Enabled) {
- Features[Name] = Enabled;
+ // This is a bit of a hack to deal with the sse4 target feature when used
+ // as part of the target attribute. We handle sse4 correctly everywhere
+ // else. See below for more information on how we handle the sse4 options.
+ if (Name != sse4)
+Features[Name] = Enabled;
if (Name == mmx) {
setMMXLevel(Features, MMX, Enabled);
@@ -2779,6 +2783,15 @@ void X86TargetInfo::setFeatureEnabledImp
} else if (Name == sha) {
if (Enabled)
setSSELevel(Features, SSE2, Enabled);
+ } else if (Name == sse4) {
+// We can get here via the __target__ attribute since that's not controlled
+// via the -msse4/-mno-sse4 command line alias. Handle this the same way
+// here - turn on the sse4.2 if enabled, turn off the sse4.1 level if
+// disabled.
+if (Enabled)
+ setSSELevel(Features, SSE42, Enabled);
+else
+ setSSELevel(Features, SSE41, Enabled);
}
}
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241130r1=241129r2=241130view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Tue Jun 30 19:08:32 2015
@@ -9,6 +9,8 @@ int __attribute__((target(fpmath=387))
int __attribute__((target(mno-sse2))) echidna(int a) { return 4; }
+int __attribute__((target(sse4))) panda(int a) { return 4; }
+
int bar(int a) { return baz(a) + foo(a); }
// Check that we emit the additional subtarget and cpu features for foo and
not for baz or bar.
@@ -23,3 +25,4 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse4.2,+ssse3,+sse3,+sse,+sse2,+sse4.1,+avx
// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=-sse4a,-sse3,-avx2,-avx512bw,-avx512er,-avx512dq,-avx512pf,-fma4,-avx512vl,+sse,-pclmul,-avx512cd,-avx,-f16c,-ssse3,-avx512f,-fma,-xop,-aes,-sha,-sse2,-sse4.1,-sse4.2
+// CHECK: #3 = {{.*}}target-cpu=x86-64
target-features=+ssse3,+sse3,+sse,+sse2,+sse4.1,+sse4.2
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r241129 - Fix a TODO dealing with canonicalizing attributes on functions by
Author: echristo
Date: Tue Jun 30 19:08:29 2015
New Revision: 241129
URL: http://llvm.org/viewvc/llvm-project?rev=241129view=rev
Log:
Fix a TODO dealing with canonicalizing attributes on functions by
using a string map to canonicalize. Fix up a couple of testcases
that needed changing since we are no longer simply appending features
to the list, but all of their mask dependencies as well.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/attr-target.c
cfe/trunk/test/CodeGen/function-target-features.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241129r1=241128r2=241129view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Jun 30 19:08:29 2015
@@ -1493,12 +1493,16 @@ void CodeGenModule::ConstructAttributeLi
// avoid putting features in the target-features set if we know it'll be
// one of the default features in the backend, e.g. corei7-avx and +avx or
// figure out non-explicit dependencies.
-std::vectorstd::string Features(getTarget().getTargetOpts().Features);
+// Canonicalize the existing features in a new feature map.
+// TODO: Migrate the existing backends to keep the map around rather than
+// the vector.
+llvm::StringMapbool FeatureMap;
+for (auto F : getTarget().getTargetOpts().Features) {
+ const char *Name = F.c_str();
+ bool Enabled = Name[0] == '+';
+ getTarget().setFeatureEnabled(FeatureMap, Name + 1, Enabled);
+}
-// TODO: The target attribute complicates this further by allowing multiple
-// additional features to be tacked on to the feature string for a
-// particular function. For now we simply append to the set of features and
-// let backend resolution fix them up.
const FunctionDecl *FD = dyn_cast_or_nullFunctionDecl(TargetDecl);
if (FD) {
if (const TargetAttr *TD = FD-getAttrTargetAttr()) {
@@ -1507,7 +1511,7 @@ void CodeGenModule::ConstructAttributeLi
FeaturesStr.split(AttrFeatures, ,);
// Grab the various features and prepend a + to turn on the feature
to
-// the backend and add them to our existing set of Features.
+// the backend and add them to our existing set of features.
for (auto Feature : AttrFeatures) {
// While we're here iterating check for a different target cpu.
if (Feature.startswith(arch=))
@@ -1521,13 +1525,21 @@ void CodeGenModule::ConstructAttributeLi
// attributes on the function.
;
else if (Feature.startswith(mno-))
-Features.push_back(- + Feature.split(-).second.str());
+getTarget().setFeatureEnabled(FeatureMap,
Feature.split(-).second,
+ false);
else
-Features.push_back(+ + Feature.str());
- }
+getTarget().setFeatureEnabled(FeatureMap, Feature, true);
+}
}
}
+// Produce the canonical string for this set of features.
+std::vectorstd::string Features;
+for (llvm::StringMapbool::const_iterator it = FeatureMap.begin(),
+ ie = FeatureMap.end();
+ it != ie; ++it)
+ Features.push_back((it-second ? + : -) + it-first().str());
+
// Now add the target-cpu and target-features to the function.
if (TargetCPU != )
FuncAttrs.addAttribute(target-cpu, TargetCPU);
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241129r1=241128r2=241129view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Tue Jun 30 19:08:29 2015
@@ -21,5 +21,5 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
-// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse,+sse2,+avx,+sse4.2
-// CHECK: #2 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2,-sse2
+// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse4.2,+ssse3,+sse3,+sse,+sse2,+sse4.1,+avx
+// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=-sse4a,-sse3,-avx2,-avx512bw,-avx512er,-avx512dq,-avx512pf,-fma4,-avx512vl,+sse,-pclmul,-avx512cd,-avx,-f16c,-ssse3,-avx512f,-fma,-xop,-aes,-sha,-sse2,-sse4.1,-sse4.2
Modified: cfe/trunk/test/CodeGen/function-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/function-target-features.c?rev=241129r1=241128r2=241129view=diff
==
--- cfe/trunk/test/CodeGen/function-target-features.c (original)
+++
r241134 - Use a stable sort to guarantee target feature ordering in the IR
Author: echristo
Date: Tue Jun 30 20:07:12 2015
New Revision: 241134
URL: http://llvm.org/viewvc/llvm-project?rev=241134view=rev
Log:
Use a stable sort to guarantee target feature ordering in the IR
in order to make testing somewhat more feasible. Has the advantage
of making it easier to find target features as well.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/arm-target-features.c
cfe/trunk/test/CodeGen/attr-target.c
cfe/trunk/test/CodeGen/function-target-features.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Jun 30 20:07:12 2015
@@ -1544,6 +1544,7 @@ void CodeGenModule::ConstructAttributeLi
if (TargetCPU != )
FuncAttrs.addAttribute(target-cpu, TargetCPU);
if (!Features.empty()) {
+ std::stable_sort(Features.begin(), Features.end());
std::stringstream TargetFeatures;
std::copy(Features.begin(), Features.end(),
std::ostream_iteratorstd::string(TargetFeatures, ,));
Modified: cfe/trunk/test/CodeGen/arm-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-target-features.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/arm-target-features.c (original)
+++ cfe/trunk/test/CodeGen/arm-target-features.c Tue Jun 30 20:07:12 2015
@@ -6,7 +6,7 @@
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a5
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
-// CHECK-VFP4: target-features=+vfp4,+neon
+// CHECK-VFP4: target-features=+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a7
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
@@ -15,14 +15,14 @@
// RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift -emit-llvm
-o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
-// CHECK-VFP4-DIV: target-features=+vfp4,+neon,+hwdiv,+hwdiv-arm
+// CHECK-VFP4-DIV: target-features=+hwdiv,+hwdiv-arm,+neon,+vfp4
// RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a72
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
-// CHECK-BASIC-V8:
target-features=+neon,+fp-armv8,+hwdiv,+crypto,+crc,+hwdiv-arm
+// CHECK-BASIC-V8:
target-features=+crc,+crypto,+fp-armv8,+hwdiv,+hwdiv-arm,+neon
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r5
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-DIV
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=241134r1=241133r2=241134view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Tue Jun 30 20:07:12 2015
@@ -23,6 +23,6 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
-// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse4.2,+ssse3,+sse3,+sse,+sse2,+sse4.1,+avx
-// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=-sse4a,-sse3,-avx2,-avx512bw,-avx512er,-avx512dq,-avx512pf,-fma4,-avx512vl,+sse,-pclmul,-avx512cd,-avx,-f16c,-ssse3,-avx512f,-fma,-xop,-aes,-sha,-sse2,-sse4.1,-sse4.2
-// CHECK: #3 = {{.*}}target-cpu=x86-64
target-features=+ssse3,+sse3,+sse,+sse2,+sse4.1,+sse4.2
+// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+avx,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3
+// CHECK: #2 = {{.*}}target-cpu=x86-64
target-features=+sse,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop
+// CHECK: #3 = {{.*}}target-cpu=x86-64
target-features=+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3
Modified: cfe/trunk/test/CodeGen/function-target-features.c
URL:
r240994 - Add support for the x86 builtin __builtin_cpu_supports.
Author: echristo
Date: Mon Jun 29 16:00:05 2015
New Revision: 240994
URL: http://llvm.org/viewvc/llvm-project?rev=240994view=rev
Log:
Add support for the x86 builtin __builtin_cpu_supports.
This matches the implementation of the gcc support for the same
feature, including checking the values set up by libgcc at runtime.
The structure looks like this:
unsigned int __cpu_vendor;
unsigned int __cpu_type;
unsigned int __cpu_subtype;
unsigned int __cpu_features[1];
with a set of enums to match various fields that are field out after
parsing the output of the cpuid instruction.
This also adds a set of errors checking for valid input (and cpu).
compiler-rt support for this and the other builtins in this family
(__builtin_cpu_init and __builtin_cpu_is) are forthcoming.
Added:
cfe/trunk/test/CodeGen/builtin-cpu-supports.c
cfe/trunk/test/Sema/builtin-cpu-supports.c
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp
Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=240994r1=240993r2=240994view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jun 29 16:00:05 2015
@@ -24,6 +24,11 @@
// FIXME: Are these nothrow/const?
+// Miscellaneous builtin for checking x86 cpu features.
+// TODO: Make this somewhat generic so that other backends
+// can use it?
+BUILTIN(__builtin_cpu_supports, bcC*, nc)
+
// 3DNow!
//
BUILTIN(__builtin_ia32_femms, v, )
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=240994r1=240993r2=240994view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Jun 29 16:00:05
2015
@@ -426,6 +426,7 @@ def warn_redecl_library_builtin : Warnin
InGroupDiagGroupincompatible-library-redeclaration;
def err_builtin_definition : Errordefinition of builtin function %0;
def err_arm_invalid_specialreg : Errorinvalid special register for builtin;
+def err_invalid_cpu_supports : Errorinvalid cpu feature string for builtin;
def warn_builtin_unknown : Warninguse of unknown builtin %0,
InGroupImplicitFunctionDeclare, DefaultError;
def warn_dyn_class_memaccess : Warning
Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=240994r1=240993r2=240994view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Mon Jun 29 16:00:05 2015
@@ -611,6 +611,9 @@ public:
}
};
+ // Validate the contents of the __builtin_cpu_supports(const char*) argument.
+ virtual bool validateCpuSupports(StringRef Name) const { return false; }
+
// validateOutputConstraint, validateInputConstraint - Checks that
// a constraint is valid and provides information about it.
// FIXME: These should return a real error instead of just true/false.
Modified: cfe/trunk/include/clang/Sema/Sema.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=240994r1=240993r2=240994view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Jun 29 16:00:05 2015
@@ -8734,6 +8734,7 @@ private:
bool SemaBuiltinARMSpecialReg(unsigned BuiltinID, CallExpr *TheCall,
int ArgNum, unsigned ExpectedFieldNum,
bool AllowName);
+ bool SemaBuiltinCpuSupports(CallExpr *TheCall);
public:
enum FormatStringType {
FST_Scanf,
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=240994r1=240993r2=240994view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Jun 29 16:00:05 2015
@@ -2215,6 +2215,7 @@ public:
Names = AddlRegNames;
NumNames = llvm::array_lengthof(AddlRegNames);
}
+ bool validateCpuSupports(StringRef Name) const override;
bool validateAsmConstraint(const char *Name,
TargetInfo::ConstraintInfo info) const override;
@@ -3338,6 +3339,33 @@ bool
Re: [PATCH] Attach attribute trap-func-name to IR function
Not sure we necessarily need a put these function attributes on the functions command line and map? Rationale? -eric http://reviews.llvm.org/D10831 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach attribute trap-func-name to IR function
Lgtm thanks.
On Mon, Jun 29, 2015, 10:35 PM Akira Hatanaka ahata...@gmail.com wrote:
Remove cc1 option and simplify patch.
http://reviews.llvm.org/D10831
Files:
lib/CodeGen/BackendUtil.cpp
lib/CodeGen/CGCall.cpp
test/CodeGen/fn-attr.c
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -536,7 +536,6 @@
Options.NoZerosInBSS = CodeGenOpts.NoZeroInitializedInBSS;
Options.UnsafeFPMath = CodeGenOpts.UnsafeFPMath;
Options.StackAlignmentOverride = CodeGenOpts.StackAlignment;
- Options.TrapFuncName = CodeGenOpts.TrapFuncName;
Options.PositionIndependentExecutable = LangOpts.PIELevel != 0;
Options.FunctionSections = CodeGenOpts.FunctionSections;
Options.DataSections = CodeGenOpts.DataSections;
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1483,6 +1483,9 @@
if (!CodeGenOpts.StackRealignment)
FuncAttrs.addAttribute(no-realign-stack);
+if (!CodeGenOpts.TrapFuncName.empty())
+ FuncAttrs.addAttribute(trap-func-name, CodeGenOpts.TrapFuncName);
+
// Add target-cpu and target-features attributes to functions. If
// we have a decl for the function and it has a target attribute then
// parse that and add it to the feature set.
Index: test/CodeGen/fn-attr.c
===
--- /dev/null
+++ test/CodeGen/fn-attr.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -triple thumbv7-apple-ios5 -function-attribute
trap-func-name=trapfuncname1 -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: attributes #0 = { {{.*}} trap-func-name=trapfuncname1
+
+int foo1(int a) { return a; }
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [X86, inlineasm] Implement v, k, Y2, Yk, Yz constraints, improve analysis for x, Y*, L, e, Z, s
Sorry for the delay, I'll get to this soon. Thanks! -eric REPOSITORY rL LLVM http://reviews.llvm.org/D10536 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute arm-restrict-it instead of passing arm-restrict-it as a backend-option
On Tue, Jun 23, 2015 at 12:03 PM Akira Hatanaka ahata...@gmail.com wrote: On Mon, Jun 22, 2015 at 2:00 PM, Eric Christopher echri...@gmail.com wrote: On Mon, Jun 22, 2015 at 1:49 PM Akira Hatanaka ahata...@gmail.com wrote: In http://reviews.llvm.org/D10414#191915, @echristo wrote: Another possibility is that this gets mapped as a normal command line option passed into cc1 and then it can just be a subtarget feature? Would it look something like this in the IR? target-features=+neon,+vfp3,arn-restrict-it=false was thinking of more just: target-features=+neon,+vfp3,-restrict-it Though if we're going for restrict-it blocks perhaps a better name that works well with +/-? I've generally stayed away from turning command line options into features, but in the case of something that appears to turn on actual code generation features it seems like it might be reasonable. Since restrict-it is a tri-state, I think you'll have to define two new subtarget features in ARM.td (see the attached patch). I'm not sure how prefixing restrict-it by - is going to work. I think default is a red herring here a bit. It's either on or off right now, we might have to bake in some back end knowledge in the front end about when to apply it, but it should still work out yes? This approach can potentially create larger numbers of subtarget objects as two subtarget objects have to be created If one function has feature restricted-it and another has feature no-restricted-it. If we take the approach in my original patch, we need only one subtarget object. Do you think that's going to be a problem? Irrespective of the above I'm not too worried about this. In general, people have a tendency to use the same command line options everywhere, especially for this sort of thing. -eric -eric http://reviews.llvm.org/D10414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute arm-restrict-it instead of passing arm-restrict-it as a backend-option
Since restrict-it is a tri-state, I think you'll have to define two new subtarget features in ARM.td (see the attached patch). I'm not sure how prefixing restrict-it by - is going to work. I think default is a red herring here a bit. It's either on or off right now, we might have to bake in some back end knowledge in the front end about when to apply it, but it should still work out yes? Yes, we'll have to know whether restrict-it or no-restrict-it was passed on command line and whether v8 is supported. As per your suggestion, I added one feature in ARM.td and then fixed getARMTargetFeatures in lib/Driver/Tools.cpp to push feature +restrict-it to the feature list based on the subarch. It seems to me that we can add code-gen options to the IR as subtarget features in most cases, but it's not clear to me when to use function attributes and when to use subtarget features. Should we convert target-specific code-gen options into subtarget features whenever it is possible to do so, and convert target-independent options into function attributes? This is what I've been thinking at the moment. I think it cleans up quite a bit of the interface mechanics etc. I've even added one more target-independent one (soft-float) as a subtarget feature because that seems to make the most sense. I think at least some of these are going to be on a case by case basis, but this seems to make the most sense to me. -eric This approach can potentially create larger numbers of subtarget objects as two subtarget objects have to be created If one function has feature restricted-it and another has feature no-restricted-it. If we take the approach in my original patch, we need only one subtarget object. Do you think that's going to be a problem? Irrespective of the above I'm not too worried about this. In general, people have a tendency to use the same command line options everywhere, especially for this sort of thing. I would think so too. -eric -eric http://reviews.llvm.org/D10414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute arm-restrict-it instead of passing arm-restrict-it as a backend-option
On Mon, Jun 22, 2015 at 1:49 PM Akira Hatanaka ahata...@gmail.com wrote: In http://reviews.llvm.org/D10414#191915, @echristo wrote: Another possibility is that this gets mapped as a normal command line option passed into cc1 and then it can just be a subtarget feature? Would it look something like this in the IR? target-features=+neon,+vfp3,arn-restrict-it=false was thinking of more just: target-features=+neon,+vfp3,-restrict-it Though if we're going for restrict-it blocks perhaps a better name that works well with +/-? I've generally stayed away from turning command line options into features, but in the case of something that appears to turn on actual code generation features it seems like it might be reasonable. -eric http://reviews.llvm.org/D10414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute arm-restrict-it instead of passing arm-restrict-it as a backend-option
Another possibility is that this gets mapped as a normal command line option passed into cc1 and then it can just be a subtarget feature? Idle thoughts of different implementation, but it avoids a lot of complication and per-target free form attributes. -eric http://reviews.llvm.org/D10414 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r240152 - Add a comment and FIXME based on the commit message that made the
Author: echristo Date: Fri Jun 19 13:09:33 2015 New Revision: 240152 URL: http://llvm.org/viewvc/llvm-project?rev=240152view=rev Log: Add a comment and FIXME based on the commit message that made the intrinsic _mm_prefetch into a builtin rather than by textual inclusion via the intrinsic headers. Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=240152r1=240151r2=240152view=diff == --- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original) +++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Fri Jun 19 13:09:33 2015 @@ -59,6 +59,9 @@ BUILTIN(__builtin_ia32_pswapdsi, V2iV2i // All MMX instructions will be generated via builtins. Any MMX vector // types (1 x i64, 2 x i32, etc.) that aren't used by these builtins will be // expanded by the back-end. +// FIXME: _mm_prefetch must be a built-in because it takes a compile-time constant +// argument and our prior approach of using a #define to the current built-in +// doesn't work in the presence of re-declaration of _mm_prefetch for windows. BUILTIN(_mm_prefetch, vcC*i, nc) BUILTIN(__builtin_ia32_emms, v, ) BUILTIN(__builtin_ia32_paddb, V8cV8cV8c, ) ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] OpenCL: Add new types for OpenCL 2.0
Please run clang-format on your patch. You still have lines over 80-columns for example. Thanks. -eric On Wed, Jun 17, 2015, 7:38 AM Pedro Ferreira arkang...@gmail.com wrote: Updated from head SVN - no conflicts. Still runs without failures. On Wed, 17 Jun 2015 at 15:08 Pedro Ferreira arkang...@gmail.com wrote: Sorry, that was my bad. I forgot to set my editor back to llvm indentation settings and it inserted tabs instead of spaces. Line 1000 of SemaTypes is 79 characters long, which is the largest (longest) line in the patch. It is the same length of line 981 from where I copy-pasted the code (by your suggestion). Grep claims the attached patch has no tabs now :) On Wed, 17 Jun 2015 at 14:47 Anastasia Stulova anastasia.stul...@arm.com wrote: I think there are still lines that are too long (especially in SemaType.cpp). Have you run clang-format on your changes? Otherwise, no further comments from my side. Anastasia *From:* Pedro Ferreira [mailto:arkang...@gmail.com] *Sent:* 15 June 2015 09:16 *To:* Eric Christopher; Anastasia Stulova; cfe-commits@cs.uiuc.edu *Subject:* Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 There were a couple lines with 80 columns, and this new patch version fixes them. On Fri, 12 Jun 2015 at 21:03 Eric Christopher echri...@gmail.com wrote: Drive by review here. I was making sure there was debug info support for the bits, thanks for adding it though I'm not seeing any tests ;) I'm pretty sure you have some 80-column violations and other formatting things, could you clang-format your patch? Thanks! -eric On Fri, Jun 12, 2015 at 4:20 AM Pedro Ferreira arkang...@gmail.com wrote: Awesome, thanks for the tips. Updated version attached. Pedro On Thu, 11 Jun 2015 at 19:23 Anastasia Stulova anastasia.stul...@arm.com wrote: CodeGen tests looks good! Regarding the extension, could you diagnose it during the type checking instead. That way it will be cover all cases. You can look at the CL2.0 atomic type implementation in SemaType.cpp ConvertDeclSpecToType. Also please reuse the same error err_type_requires_extension instead of adding the new one. Please, add Sema test demonstating the error handling works correctly. Thanks, Anastasia From: Pedro Ferreira [arkang...@gmail.com] Sent: Thursday, June 11, 2015 12:50 PM To: Anastasia Stulova; cfe-commits@cs.uiuc.edu Subject: Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 Ok, found out the right place to diagnose the extension and added the tests. I am not particularly convinced that was the best way to do it; comments welcome. Pedro On Thu, 11 Jun 2015 at 11:43 Pedro Ferreira arkang...@gmail.commailto: arkang...@gmail.com wrote: Actually, I spoke too soon - I found a test with -cl-std=CL2.0. I missed that. On Thu, 11 Jun 2015 at 11:40 Pedro Ferreira arkang...@gmail.commailto: arkang...@gmail.com wrote: The codegen test would imply adding a -cl-std=2.0 option to Clang, which it currently does not have. This is because the types should only be recognised if the CL 2.0 standard is explicitly asked for (the default is to operate on 1.2 mode). Adding that option is a peripheral issue. I've added the types on the header test under the appropriate #if defined but when I tried to do the same on the .cl file, I found out that the test parser does not recognise the preprocessor macro and therefore was causing the test to (incorrectly) fail. As such, I reverted the test. As for the AS for the other types, I copy-pasted the code from event_t. That's the reason why I'm actually using the 0. Are you suggesting I should change event_t to use something else, and by consequence the new types too? That would be a separate issue. My guess is that these types are allocated on the stack, which by llvm convention will always be 0. The new types are used by new builtins. I don't think there are any other special semantics to it. I've added extension checks on the MSAA types, but I'm not sure if this is the right place. New patch attached. Pedro On Thu, 11 Jun 2015 at 10:33 Anastasia Stulova anastasia.stul...@arm.commailto:anastasia.stul...@arm.com wrote: Hi Pedro, Could we also add a Codegen test? Also it would be better not to use constant directly as address space as the mapping could ideally be changed. Is there any reason why you generate pointers to private AS? Are there any operations allowed on new types? Any semantical checks needed? If MSAA types are part of an extension and not a part of the general standard we should ideally diagnose that extension is enabled when they are being used. Regards, Anastasia From: cfe-commits-boun...@cs.uiuc.edumailto: cfe-commits-boun...@cs.uiuc.edu [cfe-commits-boun...@cs.uiuc.edu mailto:cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Pedro Ferreira [ arkang
r240110 - Fix the the in comments/documentation/etc.
Author: echristo
Date: Thu Jun 18 20:52:53 2015
New Revision: 240110
URL: http://llvm.org/viewvc/llvm-project?rev=240110view=rev
Log:
Fix the the in comments/documentation/etc.
Modified:
cfe/trunk/docs/Modules.rst
cfe/trunk/include/clang-c/Index.h
cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
cfe/trunk/lib/Analysis/CFG.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
cfe/trunk/www/analyzer/scan-build.html
Modified: cfe/trunk/docs/Modules.rst
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/Modules.rst?rev=240110r1=240109r2=240110view=diff
==
--- cfe/trunk/docs/Modules.rst (original)
+++ cfe/trunk/docs/Modules.rst Thu Jun 18 20:52:53 2015
@@ -679,7 +679,7 @@ A *link-declaration* with the ``framewor
Configuration macros declaration
-The *config-macros-declaration* specifies the set of configuration macros that
have an effect on the the API of the enclosing module.
+The *config-macros-declaration* specifies the set of configuration macros that
have an effect on the API of the enclosing module.
.. parsed-literal::
Modified: cfe/trunk/include/clang-c/Index.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=240110r1=240109r2=240110view=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Thu Jun 18 20:52:53 2015
@@ -5633,7 +5633,7 @@ typedef enum {
* reused after indexing is finished. Set to \c NULL if you do not require it.
*
* \returns 0 on success or if there were errors from which the compiler could
- * recover. If there is a failure from which the there is no recovery, returns
+ * recover. If there is a failure from which there is no recovery, returns
* a non-zero \c CXErrorCode.
*
* The rest of the parameters are the same as #clang_parseTranslationUnit.
@@ -5664,7 +5664,7 @@ CINDEX_LINKAGE int clang_indexSourceFile
*
* The parameters are the same as #clang_indexSourceFile.
*
- * \returns If there is a failure from which the there is no recovery, returns
+ * \returns If there is a failure from which there is no recovery, returns
* non-zero, otherwise returns 0.
*/
CINDEX_LINKAGE int clang_indexTranslationUnit(CXIndexAction,
Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=240110r1=240109r2=240110view=diff
==
--- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
+++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Thu Jun 18 20:52:53 2015
@@ -1467,7 +1467,7 @@ void RecordLayoutBuilder::LayoutBitField
// ms_struct basically requests a complete replacement of the
// platform ABI's struct-layout algorithm, with the high-level goal
// of duplicating MSVC's layout. For non-bitfields, this follows
- // the the standard algorithm. The basic bitfield layout rule is to
+ // the standard algorithm. The basic bitfield layout rule is to
// allocate an entire unit of the bitfield's declared type
// (e.g. 'unsigned long'), then parcel it up among successive
// bitfields whose declared types have the same size, making a new
Modified: cfe/trunk/lib/Analysis/CFG.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp?rev=240110r1=240109r2=240110view=diff
==
--- cfe/trunk/lib/Analysis/CFG.cpp (original)
+++ cfe/trunk/lib/Analysis/CFG.cpp Thu Jun 18 20:52:53 2015
@@ -454,7 +454,7 @@ private:
TerminatorExpr(nullptr) {}
/// Returns whether we need to start a new branch for a temporary
destructor
-/// call. This is the case when the the temporary destructor is
+/// call. This is the case when the temporary destructor is
/// conditionally executed, and it is the first one we encounter while
/// visiting a subexpression - other temporary destructors at the same
level
/// will be added to the same block and are executed under the same
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=240110r1=240109r2=240110view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Jun 18 20:52:53 2015
@@ -2610,7 +2610,7 @@ static void emitWritebackArg(CodeGenFunc
LValue srcLV;
// Make an optimistic effort to emit the address as an l-value.
- // This can fail if the the argument expression is more complicated.
+ // This can fail
Re: r239883 - Update the intel intrinsic headers to use the target attribute support.
On Thu, Jun 18, 2015 at 4:21 PM Robinson, Paul
paul_robin...@playstation.sony.com wrote:
| identifies certain headers as requiring specific target features, while
with this change those headers can be legally included textually.
Um. So this change actually is not optimal for us, as a vendor targeting
exactly one chip we don't ship a complete set of clang headers, we omit the
ones that are useless. We'd need to carry a local patch that continues to
not-include the headers that we do not provide.
I'm not sure what you mean here. You would already have to protect against
a user defining a macro that would conditionally include a header so you'll
either need to keep local patches to the headers already or just ship them
all.
-eric
--paulr
*From:* Sean Silva [mailto:chisophu...@gmail.com]
*Sent:* Wednesday, June 17, 2015 3:23 PM
*To:* Robinson, Paul
*Cc:* Eric Christopher; cfe-commits@cs.uiuc.edu
*Subject:* Re: r239883 - Update the intel intrinsic headers to use the
target attribute support.
On Wed, Jun 17, 2015 at 2:19 PM, Robinson, Paul
paul_robin...@playstation.sony.com wrote:
Fewer conditionals oughta be better for modules, yes? Nice.
This change does not really affect modules. Actually it sort of makes the
situation worse because now the module map properly identifies certain
headers as requiring specific target features, while with this change those
headers can be legally included textually.
-- Sean Silva
A few inline suggestions.
--paulr
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-
boun...@cs.uiuc.edu] On Behalf Of Eric Christopher
Sent: Wednesday, June 17, 2015 12:10 AM
To: cfe-commits@cs.uiuc.edu
Subject: r239883 - Update the intel intrinsic headers to use the target
attribute support.
Author: echristo
Date: Wed Jun 17 02:09:32 2015
New Revision: 239883
URL: http://llvm.org/viewvc/llvm-project?rev=239883view=rev
Log:
Update the intel intrinsic headers to use the target attribute support.
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__((sse3 foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
Added:
cfe/trunk/test/Headers/pmmintrin.c
cfe/trunk/test/Headers/x86intrin-2.c
Modified:
cfe/trunk/lib/Headers/__wmmintrin_aes.h
cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
cfe/trunk/lib/Headers/adxintrin.h
cfe/trunk/lib/Headers/ammintrin.h
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/avx512bwintrin.h
cfe/trunk/lib/Headers/avx512dqintrin.h
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avx512vlbwintrin.h
cfe/trunk/lib/Headers/avx512vldqintrin.h
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/bmi2intrin.h
cfe/trunk/lib/Headers/bmiintrin.h
cfe/trunk/lib/Headers/emmintrin.h
cfe/trunk/lib/Headers/f16cintrin.h
cfe/trunk/lib/Headers/fma4intrin.h
cfe/trunk/lib/Headers/fmaintrin.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/lib/Headers/lzcntintrin.h
cfe/trunk/lib/Headers/mm3dnow.h
cfe/trunk/lib/Headers/mmintrin.h
cfe/trunk/lib/Headers/nmmintrin.h
cfe/trunk/lib/Headers/pmmintrin.h
cfe/trunk/lib/Headers/popcntintrin.h
cfe/trunk/lib/Headers/rdseedintrin.h
cfe/trunk/lib/Headers/rtmintrin.h
cfe/trunk/lib/Headers/shaintrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/lib/Headers/tbmintrin.h
cfe/trunk/lib/Headers/tmmintrin.h
cfe/trunk/lib/Headers/wmmintrin.h
cfe/trunk/lib/Headers/x86intrin.h
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/lib/Headers/xopintrin.h
cfe/trunk/test/Headers/x86intrin.c
Modified: cfe/trunk/lib/Headers/__wmmintrin_aes.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/__wmmintrin_aes.h?rev=239883r1=239882r2=23
9883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_aes.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_aes.h Wed Jun 17 02:09:32 2015
@@ -25,12 +25,8 @@
#include emmintrin.h
-#if !defined (__AES__)
-# error AES instructions not enabled
-#else
-
/* Define the default attributes for the functions in this file. */
-#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
+#define DEFAULT_FN_ATTRS
r239926 - Move xtest to its own file to match the gcc header organization.
Author: echristo
Date: Wed Jun 17 13:42:07 2015
New Revision: 239926
URL: http://llvm.org/viewvc/llvm-project?rev=239926view=rev
Log:
Move xtest to its own file to match the gcc header organization.
Added:
cfe/trunk/lib/Headers/xtestintrin.h
Modified:
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/test/Headers/x86intrin-2.c
Modified: cfe/trunk/lib/Headers/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/CMakeLists.txt?rev=239926r1=239925r2=239926view=diff
==
--- cfe/trunk/lib/Headers/CMakeLists.txt (original)
+++ cfe/trunk/lib/Headers/CMakeLists.txt Wed Jun 17 13:42:07 2015
@@ -62,6 +62,7 @@ set(files
x86intrin.h
xmmintrin.h
xopintrin.h
+ xtestintrin.h
)
set(output_dir ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}/include)
Modified: cfe/trunk/lib/Headers/immintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/immintrin.h?rev=239926r1=239925r2=239926view=diff
==
--- cfe/trunk/lib/Headers/immintrin.h (original)
+++ cfe/trunk/lib/Headers/immintrin.h Wed Jun 17 13:42:07 2015
@@ -136,15 +136,7 @@ _writegsbase_u64(unsigned long long __V)
#include rtmintrin.h
-/* xtest returns non-zero if the instruction is executed within an RTM or
active
- * HLE region. */
-/* FIXME: This can be an either or for RTM/HLE. Deal with this when HLE is
- * supported. */
-static __inline__ int __attribute__((__always_inline__, __nodebug__,
__target__(rtm)))
-_xtest(void)
-{
- return __builtin_ia32_xtest();
-}
+#include xtestintrin.h
#include shaintrin.h
Added: cfe/trunk/lib/Headers/xtestintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/xtestintrin.h?rev=239926view=auto
==
--- cfe/trunk/lib/Headers/xtestintrin.h (added)
+++ cfe/trunk/lib/Headers/xtestintrin.h Wed Jun 17 13:42:07 2015
@@ -0,0 +1,41 @@
+/*=== xtestintrin.h - XTEST intrinsic -===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ *===---===
+ */
+
+#ifndef __IMMINTRIN_H
+#error Never use xtestintrin.h directly; include immintrin.h instead.
+#endif
+
+#ifndef __XTESTINTRIN_H
+#define __XTESTINTRIN_H
+
+/* xtest returns non-zero if the instruction is executed within an RTM or
active
+ * HLE region. */
+/* FIXME: This can be an either or for RTM/HLE. Deal with this when HLE is
+ * supported. */
+static __inline__ int
+__attribute__((__always_inline__, __nodebug__, __target__(rtm)))
+_xtest(void) {
+ return __builtin_ia32_xtest();
+}
+
+#endif
Modified: cfe/trunk/test/Headers/x86intrin-2.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/x86intrin-2.c?rev=239926r1=239925r2=239926view=diff
==
--- cfe/trunk/test/Headers/x86intrin-2.c (original)
+++ cfe/trunk/test/Headers/x86intrin-2.c Wed Jun 17 13:42:07 2015
@@ -130,4 +130,8 @@ __m128 __attribute__((__target__(f16c)
return _mm_cvtph_ps(a);
}
+int __attribute__((__target__(rtm))) xtest_wrap(void) {
+ return _xtest();
+}
+
#endif
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r239896 - Fix clang/test/Headers/x86intrin-2.c. _readfsbase_u32() is provided in not i686 but x86-64.
Ah, thanks. I tried to get ones that were either, maybe I'll swap it around.
-eric
On Wed, Jun 17, 2015 at 3:48 AM NAKAMURA Takumi geek4ci...@gmail.com
wrote:
Author: chapuni
Date: Wed Jun 17 05:40:51 2015
New Revision: 239896
URL: http://llvm.org/viewvc/llvm-project?rev=239896view=rev
Log:
Fix clang/test/Headers/x86intrin-2.c. _readfsbase_u32() is provided in not
i686 but x86-64.
Modified:
cfe/trunk/test/Headers/x86intrin-2.c
Modified: cfe/trunk/test/Headers/x86intrin-2.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/x86intrin-2.c?rev=239896r1=239895r2=239896view=diff
==
--- cfe/trunk/test/Headers/x86intrin-2.c (original)
+++ cfe/trunk/test/Headers/x86intrin-2.c Wed Jun 17 05:40:51 2015
@@ -92,9 +92,11 @@ int __attribute__((__target__(rdrnd)))
return _rdrand16_step(p);
}
+#if defined(__x86_64__)
unsigned int __attribute__((__target__(fsgsbase)))
readfsbase_u32_wrap(void) {
return _readfsbase_u32();
}
+#endif
unsigned int __attribute__((__target__(rtm))) xbegin_wrap(void) {
return _xbegin();
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239925 - Update comments on HLE, RTM, and ADX support for intrinsics.
Author: echristo
Date: Wed Jun 17 13:42:03 2015
New Revision: 239925
URL: http://llvm.org/viewvc/llvm-project?rev=239925view=rev
Log:
Update comments on HLE, RTM, and ADX support for intrinsics.
Modified:
cfe/trunk/lib/Headers/immintrin.h
Modified: cfe/trunk/lib/Headers/immintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/immintrin.h?rev=239925r1=239924r2=239925view=diff
==
--- cfe/trunk/lib/Headers/immintrin.h (original)
+++ cfe/trunk/lib/Headers/immintrin.h Wed Jun 17 13:42:03 2015
@@ -136,7 +136,10 @@ _writegsbase_u64(unsigned long long __V)
#include rtmintrin.h
-/* FIXME: check __HLE__ as well when HLE is supported. */
+/* xtest returns non-zero if the instruction is executed within an RTM or
active
+ * HLE region. */
+/* FIXME: This can be an either or for RTM/HLE. Deal with this when HLE is
+ * supported. */
static __inline__ int __attribute__((__always_inline__, __nodebug__,
__target__(rtm)))
_xtest(void)
{
@@ -145,8 +148,8 @@ _xtest(void)
#include shaintrin.h
-/* Some intrinsics inside adxintrin.h are available only if __ADX__ defined,
- * whereas others are also available if __ADX__ undefined */
+/* Some intrinsics inside adxintrin.h are available only on processors with
ADX,
+ * whereas others are also available at all times. */
#include adxintrin.h
#endif /* __IMMINTRIN_H */
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r239883 - Update the intel intrinsic headers to use the target attribute support.
Having __attribute__ and DEFAULT_FN_ATTRIBUTE on the same line seemed
weird, but as I said, don't care too much in this case, it's just a few
#defines and updates.
-eric
On Wed, Jun 17, 2015 at 2:32 PM Robinson, Paul
paul_robin...@playstation.sony.com wrote:
Not fussed about the adxintrin.h as it's just a couple.
Did you miss the comment in immintrin.h? That's more like a dozen, seems
worthwhile there.
--paulr
*From:* Eric Christopher [mailto:echri...@gmail.com]
*Sent:* Wednesday, June 17, 2015 2:26 PM
*To:* Robinson, Paul; cfe-commits@cs.uiuc.edu
*Subject:* Re: r239883 - Update the intel intrinsic headers to use the
target attribute support.
On Wed, Jun 17, 2015 at 2:19 PM Robinson, Paul
paul_robin...@playstation.sony.com wrote:
Fewer conditionals oughta be better for modules, yes? Nice.
A few inline suggestions.
--paulr
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-
boun...@cs.uiuc.edu] On Behalf Of Eric Christopher
Sent: Wednesday, June 17, 2015 12:10 AM
To: cfe-commits@cs.uiuc.edu
Subject: r239883 - Update the intel intrinsic headers to use the target
attribute support.
Author: echristo
Date: Wed Jun 17 02:09:32 2015
New Revision: 239883
URL: http://llvm.org/viewvc/llvm-project?rev=239883view=rev
Log:
Update the intel intrinsic headers to use the target attribute support.
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__((sse3 foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
Added:
cfe/trunk/test/Headers/pmmintrin.c
cfe/trunk/test/Headers/x86intrin-2.c
Modified:
cfe/trunk/lib/Headers/__wmmintrin_aes.h
cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
cfe/trunk/lib/Headers/adxintrin.h
cfe/trunk/lib/Headers/ammintrin.h
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/avx512bwintrin.h
cfe/trunk/lib/Headers/avx512dqintrin.h
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avx512vlbwintrin.h
cfe/trunk/lib/Headers/avx512vldqintrin.h
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/bmi2intrin.h
cfe/trunk/lib/Headers/bmiintrin.h
cfe/trunk/lib/Headers/emmintrin.h
cfe/trunk/lib/Headers/f16cintrin.h
cfe/trunk/lib/Headers/fma4intrin.h
cfe/trunk/lib/Headers/fmaintrin.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/lib/Headers/lzcntintrin.h
cfe/trunk/lib/Headers/mm3dnow.h
cfe/trunk/lib/Headers/mmintrin.h
cfe/trunk/lib/Headers/nmmintrin.h
cfe/trunk/lib/Headers/pmmintrin.h
cfe/trunk/lib/Headers/popcntintrin.h
cfe/trunk/lib/Headers/rdseedintrin.h
cfe/trunk/lib/Headers/rtmintrin.h
cfe/trunk/lib/Headers/shaintrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/lib/Headers/tbmintrin.h
cfe/trunk/lib/Headers/tmmintrin.h
cfe/trunk/lib/Headers/wmmintrin.h
cfe/trunk/lib/Headers/x86intrin.h
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/lib/Headers/xopintrin.h
cfe/trunk/test/Headers/x86intrin.c
Modified: cfe/trunk/lib/Headers/__wmmintrin_aes.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/__wmmintrin_aes.h?rev=239883r1=239882r2=23
9883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_aes.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_aes.h Wed Jun 17 02:09:32 2015
@@ -25,12 +25,8 @@
#include emmintrin.h
-#if !defined (__AES__)
-# error AES instructions not enabled
-#else
-
/* Define the default attributes for the functions in this file. */
-#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
+#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,
__target__(aes)))
static __inline__ __m128i DEFAULT_FN_ATTRS
_mm_aesenc_si128(__m128i __V, __m128i __R)
@@ -67,6 +63,4 @@ _mm_aesimc_si128(__m128i __V)
#undef DEFAULT_FN_ATTRS
-#endif
-
#endif /* _WMMINTRIN_AES_H */
Modified: cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/__wmmintrin_pclmul.h?rev=239883r1=239882r2
=239883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_pclmul.h (original)
+++ cfe/trunk/lib/Headers
Re: r239883 - Update the intel intrinsic headers to use the target attribute support.
On Wed, Jun 17, 2015 at 2:19 PM Robinson, Paul
paul_robin...@playstation.sony.com wrote:
Fewer conditionals oughta be better for modules, yes? Nice.
A few inline suggestions.
--paulr
-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu [mailto:cfe-commits-
boun...@cs.uiuc.edu] On Behalf Of Eric Christopher
Sent: Wednesday, June 17, 2015 12:10 AM
To: cfe-commits@cs.uiuc.edu
Subject: r239883 - Update the intel intrinsic headers to use the target
attribute support.
Author: echristo
Date: Wed Jun 17 02:09:32 2015
New Revision: 239883
URL: http://llvm.org/viewvc/llvm-project?rev=239883view=rev
Log:
Update the intel intrinsic headers to use the target attribute support.
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__((sse3 foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
Added:
cfe/trunk/test/Headers/pmmintrin.c
cfe/trunk/test/Headers/x86intrin-2.c
Modified:
cfe/trunk/lib/Headers/__wmmintrin_aes.h
cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
cfe/trunk/lib/Headers/adxintrin.h
cfe/trunk/lib/Headers/ammintrin.h
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/avx512bwintrin.h
cfe/trunk/lib/Headers/avx512dqintrin.h
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avx512vlbwintrin.h
cfe/trunk/lib/Headers/avx512vldqintrin.h
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/bmi2intrin.h
cfe/trunk/lib/Headers/bmiintrin.h
cfe/trunk/lib/Headers/emmintrin.h
cfe/trunk/lib/Headers/f16cintrin.h
cfe/trunk/lib/Headers/fma4intrin.h
cfe/trunk/lib/Headers/fmaintrin.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/lib/Headers/lzcntintrin.h
cfe/trunk/lib/Headers/mm3dnow.h
cfe/trunk/lib/Headers/mmintrin.h
cfe/trunk/lib/Headers/nmmintrin.h
cfe/trunk/lib/Headers/pmmintrin.h
cfe/trunk/lib/Headers/popcntintrin.h
cfe/trunk/lib/Headers/rdseedintrin.h
cfe/trunk/lib/Headers/rtmintrin.h
cfe/trunk/lib/Headers/shaintrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/lib/Headers/tbmintrin.h
cfe/trunk/lib/Headers/tmmintrin.h
cfe/trunk/lib/Headers/wmmintrin.h
cfe/trunk/lib/Headers/x86intrin.h
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/lib/Headers/xopintrin.h
cfe/trunk/test/Headers/x86intrin.c
Modified: cfe/trunk/lib/Headers/__wmmintrin_aes.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/__wmmintrin_aes.h?rev=239883r1=239882r2=23
9883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_aes.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_aes.h Wed Jun 17 02:09:32 2015
@@ -25,12 +25,8 @@
#include emmintrin.h
-#if !defined (__AES__)
-# error AES instructions not enabled
-#else
-
/* Define the default attributes for the functions in this file. */
-#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
+#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,
__target__(aes)))
static __inline__ __m128i DEFAULT_FN_ATTRS
_mm_aesenc_si128(__m128i __V, __m128i __R)
@@ -67,6 +63,4 @@ _mm_aesimc_si128(__m128i __V)
#undef DEFAULT_FN_ATTRS
-#endif
-
#endif /* _WMMINTRIN_AES_H */
Modified: cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/__wmmintrin_pclmul.h?rev=239883r1=239882r2
=239883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_pclmul.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_pclmul.h Wed Jun 17 02:09:32 2015
@@ -23,12 +23,8 @@
#ifndef _WMMINTRIN_PCLMUL_H
#define _WMMINTRIN_PCLMUL_H
-#if !defined (__PCLMUL__)
-# error PCLMUL instruction is not enabled
-#else
#define _mm_clmulepi64_si128(__X, __Y, __I) \
((__m128i)__builtin_ia32_pclmulqdq128((__v2di)(__m128i)(__X), \
(__v2di)(__m128i)(__Y),
(char)(__I)))
-#endif
#endif /* _WMMINTRIN_PCLMUL_H */
Modified: cfe/trunk/lib/Headers/adxintrin.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Headers/adxintrin.h?rev=239883r1=239882r2=239883v
iew=diff
r239883 - Update the intel intrinsic headers to use the target attribute support.
Author: echristo
Date: Wed Jun 17 02:09:32 2015
New Revision: 239883
URL: http://llvm.org/viewvc/llvm-project?rev=239883view=rev
Log:
Update the intel intrinsic headers to use the target attribute support.
This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:
int __attribute__((__target__((sse3 foo(int a) {
_mm_mwait(0, 0);
return 4;
}
This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.
Added:
cfe/trunk/test/Headers/pmmintrin.c
cfe/trunk/test/Headers/x86intrin-2.c
Modified:
cfe/trunk/lib/Headers/__wmmintrin_aes.h
cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
cfe/trunk/lib/Headers/adxintrin.h
cfe/trunk/lib/Headers/ammintrin.h
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/avx512bwintrin.h
cfe/trunk/lib/Headers/avx512dqintrin.h
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avx512vlbwintrin.h
cfe/trunk/lib/Headers/avx512vldqintrin.h
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/lib/Headers/bmi2intrin.h
cfe/trunk/lib/Headers/bmiintrin.h
cfe/trunk/lib/Headers/emmintrin.h
cfe/trunk/lib/Headers/f16cintrin.h
cfe/trunk/lib/Headers/fma4intrin.h
cfe/trunk/lib/Headers/fmaintrin.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/lib/Headers/lzcntintrin.h
cfe/trunk/lib/Headers/mm3dnow.h
cfe/trunk/lib/Headers/mmintrin.h
cfe/trunk/lib/Headers/nmmintrin.h
cfe/trunk/lib/Headers/pmmintrin.h
cfe/trunk/lib/Headers/popcntintrin.h
cfe/trunk/lib/Headers/rdseedintrin.h
cfe/trunk/lib/Headers/rtmintrin.h
cfe/trunk/lib/Headers/shaintrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/lib/Headers/tbmintrin.h
cfe/trunk/lib/Headers/tmmintrin.h
cfe/trunk/lib/Headers/wmmintrin.h
cfe/trunk/lib/Headers/x86intrin.h
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/lib/Headers/xopintrin.h
cfe/trunk/test/Headers/x86intrin.c
Modified: cfe/trunk/lib/Headers/__wmmintrin_aes.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__wmmintrin_aes.h?rev=239883r1=239882r2=239883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_aes.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_aes.h Wed Jun 17 02:09:32 2015
@@ -25,12 +25,8 @@
#include emmintrin.h
-#if !defined (__AES__)
-# error AES instructions not enabled
-#else
-
/* Define the default attributes for the functions in this file. */
-#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
+#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,
__target__(aes)))
static __inline__ __m128i DEFAULT_FN_ATTRS
_mm_aesenc_si128(__m128i __V, __m128i __R)
@@ -67,6 +63,4 @@ _mm_aesimc_si128(__m128i __V)
#undef DEFAULT_FN_ATTRS
-#endif
-
#endif /* _WMMINTRIN_AES_H */
Modified: cfe/trunk/lib/Headers/__wmmintrin_pclmul.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__wmmintrin_pclmul.h?rev=239883r1=239882r2=239883view=diff
==
--- cfe/trunk/lib/Headers/__wmmintrin_pclmul.h (original)
+++ cfe/trunk/lib/Headers/__wmmintrin_pclmul.h Wed Jun 17 02:09:32 2015
@@ -23,12 +23,8 @@
#ifndef _WMMINTRIN_PCLMUL_H
#define _WMMINTRIN_PCLMUL_H
-#if !defined (__PCLMUL__)
-# error PCLMUL instruction is not enabled
-#else
#define _mm_clmulepi64_si128(__X, __Y, __I) \
((__m128i)__builtin_ia32_pclmulqdq128((__v2di)(__m128i)(__X), \
(__v2di)(__m128i)(__Y), (char)(__I)))
-#endif
#endif /* _WMMINTRIN_PCLMUL_H */
Modified: cfe/trunk/lib/Headers/adxintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/adxintrin.h?rev=239883r1=239882r2=239883view=diff
==
--- cfe/trunk/lib/Headers/adxintrin.h (original)
+++ cfe/trunk/lib/Headers/adxintrin.h Wed Jun 17 02:09:32 2015
@@ -32,8 +32,7 @@
#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
/* Intrinsics that are available only if __ADX__ defined */
-#ifdef __ADX__
-static __inline unsigned char DEFAULT_FN_ATTRS
+static __inline unsigned char __attribute__((__always_inline__, __nodebug__,
__target__(adx)))
_addcarryx_u32(unsigned char __cf, unsigned int __x, unsigned int __y,
unsigned int *__p)
{
@@ -41,14 +40,13 @@ _addcarryx_u32(unsigned char __cf, unsig
}
#ifdef __x86_64__
-static __inline unsigned char DEFAULT_FN_ATTRS
+static __inline unsigned char
Re: [PATCH] [Sparc] Make soft-float emit an error.
I thought I'd removed that.
Some inline comments on the patch. LGTM after fixed.
Thanks!
-eric
Comment at: lib/Driver/Tools.cpp:1323-1327
@@ -1322,1 +1322,7 @@
+// Only the hard-float ABI on Sparc is standardized, and it is the
+// default. GCC also supports a nonstandard soft-float ABI mode, and
+// perhaps LLVM should implement that, too. However, since llvm
+// currently does not support Sparc soft-float, at all, display an
+// error if it's requested.
+
Move this comment down to the if(SoftFloatABI) below?
Comment at: lib/Driver/Tools.cpp:1329-1331
@@ -1323,12 +1328,5 @@
+
static void getSparcTargetFeatures(const ArgList Args,
std::vectorconst char * Features) {
- bool SoftFloatABI = true;
- if (Arg *A =
- Args.getLastArg(options::OPT_msoft_float, options::OPT_mhard_float))
{
-if (A-getOption().matches(options::OPT_mhard_float))
- SoftFloatABI = false;
- }
- if (SoftFloatABI)
-Features.push_back(+soft-float);
}
This function appears empty now?
http://reviews.llvm.org/D10457
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [OPENMP] Driver support for OpenMP offloading
Quite a big patch, I'd definitely like to take a look at this as well. It relates to how some of the cuda work is progressing too. Thanks! -eric http://reviews.llvm.org/D9888 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [Sparc] Make soft-float emit an error.
Yep. Precisely. Thanks! LGTM. -eric http://reviews.llvm.org/D10457 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239782 - Use a macro for the omnipresent attributes on header functions in Intrin.h.
Author: echristo
Date: Mon Jun 15 18:20:35 2015
New Revision: 239782
URL: http://llvm.org/viewvc/llvm-project?rev=239782view=rev
Log:
Use a macro for the omnipresent attributes on header functions in Intrin.h.
Saves some typing and if someone wants to change them it makes it much easier.
Modified:
cfe/trunk/lib/Headers/Intrin.h
Modified: cfe/trunk/lib/Headers/Intrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=239782r1=239781r2=239782view=diff
==
--- cfe/trunk/lib/Headers/Intrin.h (original)
+++ cfe/trunk/lib/Headers/Intrin.h Mon Jun 15 18:20:35 2015
@@ -39,6 +39,9 @@
#include setjmp.h
#endif
+/* Define the default attributes for the functions in this file. */
+#define DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
+
#ifdef __cplusplus
extern C {
#endif
@@ -421,7 +424,7 @@ unsigned __int64 _shrx_u64(unsigned __in
* Multiply two 64-bit integers and obtain a 64-bit result.
* The low-half is returned directly and the high half is in an out parameter.
*/
-static __inline__ unsigned __int64 __attribute__((__always_inline__,
__nodebug__))
+static __inline__ unsigned __int64 DEFAULT_FN_ATTRS
_umul128(unsigned __int64 _Multiplier, unsigned __int64 _Multiplicand,
unsigned __int64 *_HighProduct) {
unsigned __int128 _FullProduct =
@@ -429,7 +432,7 @@ _umul128(unsigned __int64 _Multiplier, u
*_HighProduct = _FullProduct 64;
return _FullProduct;
}
-static __inline__ unsigned __int64 __attribute__((__always_inline__,
__nodebug__))
+static __inline__ unsigned __int64 DEFAULT_FN_ATTRS
__umulh(unsigned __int64 _Multiplier, unsigned __int64 _Multiplicand) {
unsigned __int128 _FullProduct =
(unsigned __int128)_Multiplier * (unsigned __int128)_Multiplicand;
@@ -444,54 +447,54 @@ void __cdecl _xsaveopt64(void *, unsigne
/**\
|* Bit Twiddling
\**/
-static __inline__ unsigned char __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned char DEFAULT_FN_ATTRS
_rotl8(unsigned char _Value, unsigned char _Shift) {
_Shift = 0x7;
return _Shift ? (_Value _Shift) | (_Value (8 - _Shift)) : _Value;
}
-static __inline__ unsigned char __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned char DEFAULT_FN_ATTRS
_rotr8(unsigned char _Value, unsigned char _Shift) {
_Shift = 0x7;
return _Shift ? (_Value _Shift) | (_Value (8 - _Shift)) : _Value;
}
-static __inline__ unsigned short __attribute__((__always_inline__,
__nodebug__))
+static __inline__ unsigned short DEFAULT_FN_ATTRS
_rotl16(unsigned short _Value, unsigned char _Shift) {
_Shift = 0xf;
return _Shift ? (_Value _Shift) | (_Value (16 - _Shift)) : _Value;
}
-static __inline__ unsigned short __attribute__((__always_inline__,
__nodebug__))
+static __inline__ unsigned short DEFAULT_FN_ATTRS
_rotr16(unsigned short _Value, unsigned char _Shift) {
_Shift = 0xf;
return _Shift ? (_Value _Shift) | (_Value (16 - _Shift)) : _Value;
}
-static __inline__ unsigned int __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned int DEFAULT_FN_ATTRS
_rotl(unsigned int _Value, int _Shift) {
_Shift = 0x1f;
return _Shift ? (_Value _Shift) | (_Value (32 - _Shift)) : _Value;
}
-static __inline__ unsigned int __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned int DEFAULT_FN_ATTRS
_rotr(unsigned int _Value, int _Shift) {
_Shift = 0x1f;
return _Shift ? (_Value _Shift) | (_Value (32 - _Shift)) : _Value;
}
-static __inline__ unsigned long __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned long DEFAULT_FN_ATTRS
_lrotl(unsigned long _Value, int _Shift) {
_Shift = 0x1f;
return _Shift ? (_Value _Shift) | (_Value (32 - _Shift)) : _Value;
}
-static __inline__ unsigned long __attribute__((__always_inline__, __nodebug__))
+static __inline__ unsigned long DEFAULT_FN_ATTRS
_lrotr(unsigned long _Value, int _Shift) {
_Shift = 0x1f;
return _Shift ? (_Value _Shift) | (_Value (32 - _Shift)) : _Value;
}
static
-__inline__ unsigned __int64 __attribute__((__always_inline__, __nodebug__))
+__inline__ unsigned __int64 DEFAULT_FN_ATTRS
_rotl64(unsigned __int64 _Value, int _Shift) {
_Shift = 0x3f;
return _Shift ? (_Value _Shift) | (_Value (64 - _Shift)) : _Value;
}
static
-__inline__ unsigned __int64 __attribute__((__always_inline__, __nodebug__))
+__inline__ unsigned __int64 DEFAULT_FN_ATTRS
_rotr64(unsigned __int64 _Value, int _Shift) {
_Shift = 0x3f;
return _Shift ? (_Value _Shift) | (_Value (64 - _Shift)) : _Value;
@@ -499,52 +502,52 @@ _rotr64(unsigned __int64 _Value, int _Sh
/**\
|* Bit Counting and Testing
Re: [PATCH] OpenCL: Add new types for OpenCL 2.0
Drive by review here. I was making sure there was debug info support for the bits, thanks for adding it though I'm not seeing any tests ;) I'm pretty sure you have some 80-column violations and other formatting things, could you clang-format your patch? Thanks! -eric On Fri, Jun 12, 2015 at 4:20 AM Pedro Ferreira arkang...@gmail.com wrote: Awesome, thanks for the tips. Updated version attached. Pedro On Thu, 11 Jun 2015 at 19:23 Anastasia Stulova anastasia.stul...@arm.com wrote: CodeGen tests looks good! Regarding the extension, could you diagnose it during the type checking instead. That way it will be cover all cases. You can look at the CL2.0 atomic type implementation in SemaType.cpp ConvertDeclSpecToType. Also please reuse the same error err_type_requires_extension instead of adding the new one. Please, add Sema test demonstating the error handling works correctly. Thanks, Anastasia From: Pedro Ferreira [arkang...@gmail.com] Sent: Thursday, June 11, 2015 12:50 PM To: Anastasia Stulova; cfe-commits@cs.uiuc.edu Subject: Re: [PATCH] OpenCL: Add new types for OpenCL 2.0 Ok, found out the right place to diagnose the extension and added the tests. I am not particularly convinced that was the best way to do it; comments welcome. Pedro On Thu, 11 Jun 2015 at 11:43 Pedro Ferreira arkang...@gmail.commailto: arkang...@gmail.com wrote: Actually, I spoke too soon - I found a test with -cl-std=CL2.0. I missed that. On Thu, 11 Jun 2015 at 11:40 Pedro Ferreira arkang...@gmail.commailto: arkang...@gmail.com wrote: The codegen test would imply adding a -cl-std=2.0 option to Clang, which it currently does not have. This is because the types should only be recognised if the CL 2.0 standard is explicitly asked for (the default is to operate on 1.2 mode). Adding that option is a peripheral issue. I've added the types on the header test under the appropriate #if defined but when I tried to do the same on the .cl file, I found out that the test parser does not recognise the preprocessor macro and therefore was causing the test to (incorrectly) fail. As such, I reverted the test. As for the AS for the other types, I copy-pasted the code from event_t. That's the reason why I'm actually using the 0. Are you suggesting I should change event_t to use something else, and by consequence the new types too? That would be a separate issue. My guess is that these types are allocated on the stack, which by llvm convention will always be 0. The new types are used by new builtins. I don't think there are any other special semantics to it. I've added extension checks on the MSAA types, but I'm not sure if this is the right place. New patch attached. Pedro On Thu, 11 Jun 2015 at 10:33 Anastasia Stulova anastasia.stul...@arm.com mailto:anastasia.stul...@arm.com wrote: Hi Pedro, Could we also add a Codegen test? Also it would be better not to use constant directly as address space as the mapping could ideally be changed. Is there any reason why you generate pointers to private AS? Are there any operations allowed on new types? Any semantical checks needed? If MSAA types are part of an extension and not a part of the general standard we should ideally diagnose that extension is enabled when they are being used. Regards, Anastasia From: cfe-commits-boun...@cs.uiuc.edumailto: cfe-commits-boun...@cs.uiuc.edu [cfe-commits-boun...@cs.uiuc.edumailto: cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Pedro Ferreira [ arkang...@gmail.commailto:arkang...@gmail.com] Sent: Thursday, June 11, 2015 8:18 AM To: cfe-commits@cs.uiuc.edumailto:cfe-commits@cs.uiuc.edu Subject: [PATCH] OpenCL: Add new types for OpenCL 2.0 Hi all, This patch adds the new OpenCL types for 2.0 described at https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/otherDataTypes.html https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_cl_sdk_2.0_docs_man_xhtml_otherDataTypes.htmld=AwMFaQc=8hUWFZcy2Z-Za5rBPlktOQr=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxkm=9Bdb39VF2l8sby_fS5dvbUnJSVMkbUEkua5v-UqAuGYs=5Dqa4a6V-GRZkKn3l59ia5wJtJJzBqEjUrQlOV-8t-we= https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_cl_sdk_2.0_docs_man_xhtml_otherDataTypes.htmld=AwMFaQc=8hUWFZcy2Z-Za5rBPlktOQr=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxkm=42YnWExwxwpeU6GPDY2_3RFxCqQakUbj_CXZsMsQ2jUs=REOBNoaDio7qDyIDCqmXhxFvZYjMOK6vuXAttjOVsNIe= I also opened https://llvm.org/bugs/show_bug.cgi?id=23794 https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23794d=AwMFaQc=8hUWFZcy2Z-Za5rBPlktOQr=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxkm=9Bdb39VF2l8sby_fS5dvbUnJSVMkbUEkua5v-UqAuGYs=DaxUQk4vxUwKYs93ZTAVu1S6Hdg2CQ1J96KmGJWtfDge=
Re: r239583 - Add a warning for unsupported elements of the target attribute.
Hi Aaron,
I've committed the patch with the quoting in r239635.
As we spoke on irc we're not doing individual string checking on these two
substrings of possible program strings so I'm going to leave them as it is,
if we do end up checking or matching then yes, I agree a StringSwitch would
make sense.
Thanks a ton for the review :)
-eric
On Fri, Jun 12, 2015 at 6:03 AM Aaron Ballman aa...@aaronballman.com
wrote:
On Thu, Jun 11, 2015 at 9:36 PM, Eric Christopher echri...@gmail.com
wrote:
Author: echristo
Date: Thu Jun 11 20:36:05 2015
New Revision: 239583
URL: http://llvm.org/viewvc/llvm-project?rev=239583view=rev
Log:
Add a warning for unsupported elements of the target attribute.
Since we're ignoring the tune= and fpmath= attributes go ahead
and add a warning alerting people to the fact that we're going
to ignore that part of it during code generation and tie it to
the attribute warning set.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Sema/attr-target.c
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jun 11
20:36:05 2015
@@ -1974,8 +1974,11 @@ def err_attribute_too_few_arguments : Er
def err_attribute_invalid_vector_type : Errorinvalid vector element
type %0;
def err_attribute_bad_neon_vector_size : Error
Neon vector size must be 64 or 128 bits;
-def err_attribute_unsupported : Error
- %0 attribute is not supported for this target;
+def warn_unsupported_target_attribute
+: WarningIgnoring unsupported %0 in the target attribute string,
+InGroupIgnoredAttributes;
Please ensure that %0 is quoted properly.
+def err_attribute_unsupported
+: Error%0 attribute is not supported for this target;
// The err_*_attribute_argument_not_int are seperate because they're
used by
// VerifyIntegerConstantExpression.
def err_aligned_attribute_argument_not_int : Error
Modified: cfe/trunk/include/clang/Sema/Sema.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Thu Jun 11 20:36:05 2015
@@ -2820,6 +2820,7 @@ public:
unsigned ArgNum, StringRef Str,
SourceLocation *ArgLocation =
nullptr);
bool checkSectionName(SourceLocation LiteralLoc, StringRef Str);
+ void checkTargetAttr(SourceLocation LiteralLoc, StringRef Str);
bool checkMSInheritanceAttrOnDefinition(
CXXRecordDecl *RD, SourceRange Range, bool BestCase,
MSInheritanceAttr::Spelling SemanticSpelling);
Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Jun 11 20:36:05 2015
@@ -2397,14 +2397,22 @@ static void handleSectionAttr(Sema S, D
D-addAttr(NewAttr);
}
+// Check for things we'd like to warn about, no errors or validation
for now.
+// TODO: Validation should use a backend target library that specifies
+// the allowable subtarget features and cpus. We could use something
like a
+// TargetCodeGenInfo hook here to do validation.
+void Sema::checkTargetAttr(SourceLocation LiteralLoc, StringRef
AttrStr) {
+ for (auto Str : {tune=, fpmath=})
+if (AttrStr.find(Str) != StringRef::npos)
+ Diag(LiteralLoc, diag::warn_unsupported_target_attribute) Str;
I know this only has two entries right now and is going to change
someday, but a StringSwitch would make me happier.
+}
+
static void handleTargetAttr(Sema S, Decl *D, const AttributeList
Attr) {
- // TODO: Validation should use a backend target library that specifies
- // the allowable subtarget features and cpus. We could use something
like a
- // TargetCodeGenInfo hook here to do validation.
StringRef Str;
SourceLocation LiteralLoc;
if (!S.checkStringLiteralArgumentAttr(Attr, 0, Str, LiteralLoc))
return;
+ S.checkTargetAttr(LiteralLoc, Str);
unsigned Index = Attr.getAttributeSpellingListIndex();
TargetAttr *NewAttr =
::new (S.Context) TargetAttr(Attr.getRange(), S.Context, Str,
Index
r239635 - Quote the user provided string in the warning message and update
Author: echristo
Date: Fri Jun 12 15:13:50 2015
New Revision: 239635
URL: http://llvm.org/viewvc/llvm-project?rev=239635view=rev
Log:
Quote the user provided string in the warning message and update
tests accordingly.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/test/Sema/attr-target.c
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=239635r1=239634r2=239635view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jun 12 15:13:50
2015
@@ -1975,7 +1975,7 @@ def err_attribute_invalid_vector_type :
def err_attribute_bad_neon_vector_size : Error
Neon vector size must be 64 or 128 bits;
def warn_unsupported_target_attribute
-: WarningIgnoring unsupported %0 in the target attribute string,
+: WarningIgnoring unsupported '%0' in the target attribute string,
InGroupIgnoredAttributes;
def err_attribute_unsupported
: Error%0 attribute is not supported for this target;
Modified: cfe/trunk/test/Sema/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-target.c?rev=239635r1=239634r2=239635view=diff
==
--- cfe/trunk/test/Sema/attr-target.c (original)
+++ cfe/trunk/test/Sema/attr-target.c Fri Jun 12 15:13:50 2015
@@ -2,7 +2,7 @@
int __attribute__((target(avx,sse4.2,arch=ivybridge))) foo() { return 4; }
int __attribute__((target())) bar() { return 4; } //expected-error {{'target'
attribute takes one argument}}
-int __attribute__((target(tune=sandybridge))) baz() { return 4; }
//expected-warning {{Ignoring unsupported tune= in the target attribute string}}
-int __attribute__((target(fpmath=387))) walrus() { return 4; }
//expected-warning {{Ignoring unsupported fpmath= in the target attribute
string}}
+int __attribute__((target(tune=sandybridge))) baz() { return 4; }
//expected-warning {{Ignoring unsupported 'tune=' in the target attribute
string}}
+int __attribute__((target(fpmath=387))) walrus() { return 4; }
//expected-warning {{Ignoring unsupported 'fpmath=' in the target attribute
string}}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239579 - Add support for the the target attribute.
Author: echristo
Date: Thu Jun 11 20:35:52 2015
New Revision: 239579
URL: http://llvm.org/viewvc/llvm-project?rev=239579view=rev
Log:
Add support for the the target attribute.
Modeled after the gcc attribute of the same name, this feature
allows source level annotations to correspond to backend code
generation. In llvm particular parlance, this allows the adding
of subtarget features and changing the cpu for a particular function
based on source level hints.
This has been added into the existing support for function level
attributes without particular verification for any target outside
of whether or not the backend will support the features/cpu given
(similar to section, etc).
Added:
cfe/trunk/test/CodeGen/attr-target.c
cfe/trunk/test/Sema/attr-target.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=239579r1=239578r2=239579view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Jun 11 20:35:52 2015
@@ -1250,6 +1250,14 @@ def Pascal : InheritableAttr {
let Documentation = [Undocumented];
}
+def Target : InheritableAttr {
+ let Spellings = [GCCtarget];
+ let Args = [StringArgumentfeatures];
+ let Subjects =
+ SubjectList[Function], ErrorDiag, ExpectedFunctionMethodOrClass;
+ let Documentation = [Undocumented];
+}
+
def TransparentUnion : InheritableAttr {
let Spellings = [GCCtransparent_union];
// let Subjects = SubjectList[Record, TypedefName];
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=239579r1=239578r2=239579view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Jun 11 20:35:52 2015
@@ -1483,24 +1483,52 @@ void CodeGenModule::ConstructAttributeLi
if (!CodeGenOpts.StackRealignment)
FuncAttrs.addAttribute(no-realign-stack);
-// Add target-cpu and target-features work if they differ from the
defaults.
-std::string CPU = getTarget().getTargetOpts().CPU;
-if (CPU != )
- FuncAttrs.addAttribute(target-cpu, CPU);
+// Add target-cpu and target-features attributes to functions. If
+// we have a decl for the function and it has a target attribute then
+// parse that and add it to the feature set.
+StringRef TargetCPU = getTarget().getTargetOpts().CPU;
// TODO: Features gets us the features on the command line including
// feature dependencies. For canonicalization purposes we might want to
-// avoid putting features in the target-features set if we know it'll be
one
-// of the default features in the backend, e.g. corei7-avx and +avx or
figure
-// out non-explicit dependencies.
-std::vectorstd::string Features = getTarget().getTargetOpts().Features;
+// avoid putting features in the target-features set if we know it'll be
+// one of the default features in the backend, e.g. corei7-avx and +avx or
+// figure out non-explicit dependencies.
+std::vectorstd::string Features(getTarget().getTargetOpts().Features);
+
+// TODO: The target attribute complicates this further by allowing multiple
+// additional features to be tacked on to the feature string for a
+// particular function. For now we simply append to the set of features and
+// let backend resolution fix them up.
+const FunctionDecl *FD = dyn_cast_or_nullFunctionDecl(TargetDecl);
+if (FD) {
+ if (const TargetAttr *TD = FD-getAttrTargetAttr()) {
+StringRef FeaturesStr = TD-getFeatures();
+SmallVectorStringRef, 1 AttrFeatures;
+FeaturesStr.split(AttrFeatures, ,);
+
+// Grab the various features and prepend a + to turn on the feature
to
+// the backend and add them to our existing set of Features.
+for (auto Feature : AttrFeatures) {
+ // While we're here iterating check for a different target cpu.
+ if (Feature.startswith(arch=))
+TargetCPU = Feature.split(=).second;
+ else
+ Features.push_back(+ + Feature.str());
+ }
+ }
+}
+
+// Now add the target-cpu and target-features to the function.
+if (TargetCPU != )
+ FuncAttrs.addAttribute(target-cpu, TargetCPU);
if (!Features.empty()) {
- std::stringstream S;
+ std::stringstream TargetFeatures;
std::copy(Features.begin(), Features.end(),
-std::ostream_iteratorstd::string(S, ,));
+std::ostream_iteratorstd::string(TargetFeatures, ,));
+
// The drop_back gets rid of the trailing space.
FuncAttrs.addAttribute(target-features,
-
r239580 - Add support for tune= to the target attribute support by ignoring it.
Author: echristo
Date: Thu Jun 11 20:35:56 2015
New Revision: 239580
URL: http://llvm.org/viewvc/llvm-project?rev=239580view=rev
Log:
Add support for tune= to the target attribute support by ignoring it.
We don't currently support the -mtune option in any useful way
so ignoring the annotation is fine.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/attr-target.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=239580r1=239579r2=239580view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Jun 11 20:35:56 2015
@@ -1512,6 +1512,9 @@ void CodeGenModule::ConstructAttributeLi
// While we're here iterating check for a different target cpu.
if (Feature.startswith(arch=))
TargetCPU = Feature.split(=).second;
+ else if (Feature.startswith(tune=))
+ // We don't support cpu tuning this way currently.
+ ;
else
Features.push_back(+ + Feature.str());
}
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=239580r1=239579r2=239580view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Thu Jun 11 20:35:56 2015
@@ -4,11 +4,15 @@ int baz(int a) { return 4; }
int __attribute__((target(avx,sse4.2,arch=ivybridge))) foo(int a) { return
4; }
+int __attribute__((target(tune=sandybridge))) walrus(int a) { return 4; }
+
int bar(int a) { return baz(a) + foo(a); }
// Check that we emit the additional subtarget and cpu features for foo and
not for baz or bar.
// CHECK: baz{{.*}} #0
// CHECK: foo{{.*}} #1
+// We ignore the tune attribute so walrus should be identical to baz and bar.
+// CHECK: walrus{{.*}} #0
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse,+sse2,+avx,+sse4.2
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239581 - Handle -mno-feature in target attribute strings by replacing the
Author: echristo
Date: Thu Jun 11 20:35:58 2015
New Revision: 239581
URL: http://llvm.org/viewvc/llvm-project?rev=239581view=rev
Log:
Handle -mno-feature in target attribute strings by replacing the
-mno- with a -feature to match how we handle this in the rest
of the frontend.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/attr-target.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=239581r1=239580r2=239581view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Jun 11 20:35:58 2015
@@ -1515,8 +1515,10 @@ void CodeGenModule::ConstructAttributeLi
else if (Feature.startswith(tune=))
// We don't support cpu tuning this way currently.
;
- else
- Features.push_back(+ + Feature.str());
+ else if (Feature.startswith(mno-))
+Features.push_back(- + Feature.split(-).second.str());
+ else
+Features.push_back(+ + Feature.str());
}
}
}
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=239581r1=239580r2=239581view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Thu Jun 11 20:35:58 2015
@@ -6,6 +6,8 @@ int __attribute__((target(avx,sse4.2,ar
int __attribute__((target(tune=sandybridge))) walrus(int a) { return 4; }
+int __attribute__((target(mno-sse2))) echidna(int a) { return 4; }
+
int bar(int a) { return baz(a) + foo(a); }
// Check that we emit the additional subtarget and cpu features for foo and
not for baz or bar.
@@ -13,6 +15,8 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: foo{{.*}} #1
// We ignore the tune attribute so walrus should be identical to baz and bar.
// CHECK: walrus{{.*}} #0
+// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
// CHECK: #1 = {{.*}}target-cpu=ivybridge
target-features=+sse,+sse2,+avx,+sse4.2
+// CHECK: #2 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2,-sse2
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239583 - Add a warning for unsupported elements of the target attribute.
Author: echristo
Date: Thu Jun 11 20:36:05 2015
New Revision: 239583
URL: http://llvm.org/viewvc/llvm-project?rev=239583view=rev
Log:
Add a warning for unsupported elements of the target attribute.
Since we're ignoring the tune= and fpmath= attributes go ahead
and add a warning alerting people to the fact that we're going
to ignore that part of it during code generation and tie it to
the attribute warning set.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Sema/attr-target.c
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jun 11 20:36:05
2015
@@ -1974,8 +1974,11 @@ def err_attribute_too_few_arguments : Er
def err_attribute_invalid_vector_type : Errorinvalid vector element type
%0;
def err_attribute_bad_neon_vector_size : Error
Neon vector size must be 64 or 128 bits;
-def err_attribute_unsupported : Error
- %0 attribute is not supported for this target;
+def warn_unsupported_target_attribute
+: WarningIgnoring unsupported %0 in the target attribute string,
+InGroupIgnoredAttributes;
+def err_attribute_unsupported
+: Error%0 attribute is not supported for this target;
// The err_*_attribute_argument_not_int are seperate because they're used by
// VerifyIntegerConstantExpression.
def err_aligned_attribute_argument_not_int : Error
Modified: cfe/trunk/include/clang/Sema/Sema.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Thu Jun 11 20:36:05 2015
@@ -2820,6 +2820,7 @@ public:
unsigned ArgNum, StringRef Str,
SourceLocation *ArgLocation = nullptr);
bool checkSectionName(SourceLocation LiteralLoc, StringRef Str);
+ void checkTargetAttr(SourceLocation LiteralLoc, StringRef Str);
bool checkMSInheritanceAttrOnDefinition(
CXXRecordDecl *RD, SourceRange Range, bool BestCase,
MSInheritanceAttr::Spelling SemanticSpelling);
Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Jun 11 20:36:05 2015
@@ -2397,14 +2397,22 @@ static void handleSectionAttr(Sema S, D
D-addAttr(NewAttr);
}
+// Check for things we'd like to warn about, no errors or validation for now.
+// TODO: Validation should use a backend target library that specifies
+// the allowable subtarget features and cpus. We could use something like a
+// TargetCodeGenInfo hook here to do validation.
+void Sema::checkTargetAttr(SourceLocation LiteralLoc, StringRef AttrStr) {
+ for (auto Str : {tune=, fpmath=})
+if (AttrStr.find(Str) != StringRef::npos)
+ Diag(LiteralLoc, diag::warn_unsupported_target_attribute) Str;
+}
+
static void handleTargetAttr(Sema S, Decl *D, const AttributeList Attr) {
- // TODO: Validation should use a backend target library that specifies
- // the allowable subtarget features and cpus. We could use something like a
- // TargetCodeGenInfo hook here to do validation.
StringRef Str;
SourceLocation LiteralLoc;
if (!S.checkStringLiteralArgumentAttr(Attr, 0, Str, LiteralLoc))
return;
+ S.checkTargetAttr(LiteralLoc, Str);
unsigned Index = Attr.getAttributeSpellingListIndex();
TargetAttr *NewAttr =
::new (S.Context) TargetAttr(Attr.getRange(), S.Context, Str, Index);
Modified: cfe/trunk/test/Sema/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-target.c?rev=239583r1=239582r2=239583view=diff
==
--- cfe/trunk/test/Sema/attr-target.c (original)
+++ cfe/trunk/test/Sema/attr-target.c Thu Jun 11 20:36:05 2015
@@ -2,5 +2,7 @@
int __attribute__((target(avx,sse4.2,arch=ivybridge))) foo() { return 4; }
int __attribute__((target())) bar() { return 4; } //expected-error {{'target'
attribute takes one argument}}
+int __attribute__((target(tune=sandybridge))) baz() { return 4; }
//expected-warning {{Ignoring unsupported tune= in the target attribute string}}
+int __attribute__((target(fpmath=387))) walrus() { return 4; }
//expected-warning {{Ignoring unsupported fpmath= in the target attribute
r239582 - Handle fpmath= in the target attribute.
Author: echristo
Date: Thu Jun 11 20:36:00 2015
New Revision: 239582
URL: http://llvm.org/viewvc/llvm-project?rev=239582view=rev
Log:
Handle fpmath= in the target attribute.
Right now we're ignoring the fpmath attribute since there's no
backend support for a feature like this and to do so would require
checking the validity of the strings and doing general subtarget
feature parsing of valid and invalid features with the target
attribute feature.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/attr-target.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=239582r1=239581r2=239582view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Jun 11 20:36:00 2015
@@ -1515,6 +1515,11 @@ void CodeGenModule::ConstructAttributeLi
else if (Feature.startswith(tune=))
// We don't support cpu tuning this way currently.
;
+ else if (Feature.startswith(fpmath=))
+ // TODO: Support the fpmath option this way. It will require
checking
+ // overall feature validity for the function with the rest of the
+ // attributes on the function.
+ ;
else if (Feature.startswith(mno-))
Features.push_back(- + Feature.split(-).second.str());
else
Modified: cfe/trunk/test/CodeGen/attr-target.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target.c?rev=239582r1=239581r2=239582view=diff
==
--- cfe/trunk/test/CodeGen/attr-target.c (original)
+++ cfe/trunk/test/CodeGen/attr-target.c Thu Jun 11 20:36:00 2015
@@ -5,6 +5,7 @@ int baz(int a) { return 4; }
int __attribute__((target(avx,sse4.2,arch=ivybridge))) foo(int a) { return
4; }
int __attribute__((target(tune=sandybridge))) walrus(int a) { return 4; }
+int __attribute__((target(fpmath=387))) koala(int a) { return 4; }
int __attribute__((target(mno-sse2))) echidna(int a) { return 4; }
@@ -15,6 +16,8 @@ int bar(int a) { return baz(a) + foo(a);
// CHECK: foo{{.*}} #1
// We ignore the tune attribute so walrus should be identical to baz and bar.
// CHECK: walrus{{.*}} #0
+// We're currently ignoring the fpmath attribute so koala should be identical
to baz and bar.
+// CHECK: koala{{.*}} #0
// CHECK: echidna{{.*}} #2
// CHECK: bar{{.*}} #0
// CHECK: #0 = {{.*}}target-cpu=x86-64 target-features=+sse,+sse2
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
Sounds good. :) -eric http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
Sounds good. :) -eric On Tue, Jun 9, 2015 at 1:05 PM Artem Belevich t...@google.com wrote: Plan C: I'll reuse existing -mlink-bitcode-file. http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Attach function attribute disable-tail-calls
This is fine with me, thanks. -eric http://reviews.llvm.org/D10100 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [PowerPC] Reformat altivec.h with clang-format
I'm obviously cool with this, should make sure Hal and Bill are also ok. -eric http://reviews.llvm.org/D10317 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
Cool. I think that's probably how we should go. Thanks! -eric On Mon, Jun 8, 2015 at 3:23 PM Peter Collingbourne pe...@pcc.me.uk wrote: I was the person who originally introduced this flag in r143314. As I recall this flag was introduced in order to support linking a bitcode module containing an implementation of a runtime library for a GPU (e.g. libclc). The reason I made the flag link the bitcode after compilation was that I wanted to avoid breaking any invariants that Clang's code generator might have (e.g. if both the bitcode file and the C source file define a weak symbol, Clang's IR generator may get confused by the presence of a duplicate symbol, whereas the IR linker already knows to discard one of them). If avoiding the IR linker provides a significant performance advantage, it does seem reasonable to make `-mlink-bitcode-file` pre-populate the module, and start fixing any assumptions we're currently making in the IR generator. http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
Cool. I think that's probably how we should go. Thanks! -eric http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r239193 - Rename the single non-style conformant function in TargetCodeGenInfo
Author: echristo
Date: Fri Jun 5 17:03:00 2015
New Revision: 239193
URL: http://llvm.org/viewvc/llvm-project?rev=239193view=rev
Log:
Rename the single non-style conformant function in TargetCodeGenInfo
and update all callers.
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/CodeGen/TargetInfo.h
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=239193r1=239192r2=239193view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri Jun 5 17:03:00 2015
@@ -836,7 +836,7 @@ void CodeGenModule::setNonAliasAttribute
if (const SectionAttr *SA = D-getAttrSectionAttr())
GO-setSection(SA-getName());
- getTargetCodeGenInfo().SetTargetAttributes(D, GO, *this);
+ getTargetCodeGenInfo().setTargetAttributes(D, GO, *this);
}
void CodeGenModule::SetInternalFunctionAttributes(const Decl *D,
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=239193r1=239192r2=239193view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri Jun 5 17:03:00 2015
@@ -649,7 +649,7 @@ public:
static bool isStructReturnInRegABI(
const llvm::Triple Triple, const CodeGenOptions Opts);
- void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const override;
int getDwarfEHStackPointer(CodeGen::CodeGenModule CGM) const override {
@@ -1331,7 +1331,7 @@ bool X86_32TargetCodeGenInfo::isStructRe
}
}
-void X86_32TargetCodeGenInfo::SetTargetAttributes(const Decl *D,
+void X86_32TargetCodeGenInfo::setTargetAttributes(const Decl *D,
llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const
{
if (const FunctionDecl *FD = dyn_castFunctionDecl(D)) {
@@ -1665,7 +1665,7 @@ public:
bool d, bool p, bool w, unsigned RegParms)
: X86_32TargetCodeGenInfo(CGT, d, p, w, RegParms) {}
- void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const override;
void getDependentLibraryOption(llvm::StringRef Lib,
@@ -1694,10 +1694,10 @@ static void addStackProbeSizeTargetAttri
}
}
-void WinX86_32TargetCodeGenInfo::SetTargetAttributes(const Decl *D,
+void WinX86_32TargetCodeGenInfo::setTargetAttributes(const Decl *D,
llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const
{
- X86_32TargetCodeGenInfo::SetTargetAttributes(D, GV, CGM);
+ X86_32TargetCodeGenInfo::setTargetAttributes(D, GV, CGM);
addStackProbeSizeTargetAttribute(D, GV, CGM);
}
@@ -1709,7 +1709,7 @@ public:
WinX86_64TargetCodeGenInfo(CodeGen::CodeGenTypes CGT)
: TargetCodeGenInfo(new WinX86_64ABIInfo(CGT)) {}
- void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const override;
int getDwarfEHStackPointer(CodeGen::CodeGenModule CGM) const override {
@@ -1743,10 +1743,10 @@ public:
}
};
-void WinX86_64TargetCodeGenInfo::SetTargetAttributes(const Decl *D,
+void WinX86_64TargetCodeGenInfo::setTargetAttributes(const Decl *D,
llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const
{
- TargetCodeGenInfo::SetTargetAttributes(D, GV, CGM);
+ TargetCodeGenInfo::setTargetAttributes(D, GV, CGM);
addStackProbeSizeTargetAttribute(D, GV, CGM);
}
@@ -4537,7 +4537,7 @@ public:
return TargetCodeGenInfo::getSizeOfUnwindException();
}
- void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const override {
const FunctionDecl *FD = dyn_castFunctionDecl(D);
if (!FD)
@@ -4584,7 +4584,7 @@ public:
WindowsARMTargetCodeGenInfo(CodeGenTypes CGT, ARMABIInfo::ABIKind K)
: ARMTargetCodeGenInfo(CGT, K) {}
- void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule CGM) const override;
};
@@ -4600,9 +4600,9 @@ void WindowsARMTargetCodeGenInfo::addSta
r239194 - Fix typo of function name.
Author: echristo
Date: Fri Jun 5 17:03:01 2015
New Revision: 239194
URL: http://llvm.org/viewvc/llvm-project?rev=239194view=rev
Log:
Fix typo of function name.
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.h
Modified: cfe/trunk/lib/CodeGen/TargetInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.h?rev=239194r1=239193r2=239194view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.h (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.h Fri Jun 5 17:03:01 2015
@@ -58,7 +58,7 @@ public:
virtual void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule M) const {}
- /// EmitTargetMD - Provides a convenient hook to handle extra
+ /// emitTargetMD - Provides a convenient hook to handle extra
/// target-specific metadata for the given global.
virtual void emitTargetMD(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule M) const {}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Fix for PR14269: Clang crashes when a bit field is used as inline assembler input / output with memory constraint
One inline comment and then LGTM. Thanks! -eric Comment at: lib/Sema/SemaStmtAsm.cpp:241 @@ -232,1 +240,3 @@ +// Bit field can't be referenced with a pointer. +if (Info.allowsMemory() InputExpr-refersToBitField()) Bit field - Bitfield please. http://reviews.llvm.org/D10086 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [PowerPC] Add some of the missing predefined functions to altivec.h
Yes probably. :) On Mon, Jun 1, 2015, 7:56 AM Bill Seurer seu...@linux.vnet.ibm.com wrote: Reformat altivec.h and/or the test case(s)? I might as well do that now if we are going to do it. http://reviews.llvm.org/D10131 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [PowerPC] Add missing predefined functions to altivec.h
I think you're missing things like vec_abs(double), vec_add(double), etc? At least from the gcc documentation I mentioned. Also POWER8_VECTOR and not VSX? -eric http://reviews.llvm.org/D10131 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [PowerPC] Add some of the missing predefined functions to altivec.h
Looks fine to me. I'd probably want to reformat the file at some point using clang format, but that's up to others. -eric http://reviews.llvm.org/D10131 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r238630 - Fix 80-column violations.
Author: echristo
Date: Fri May 29 18:09:49 2015
New Revision: 238630
URL: http://llvm.org/viewvc/llvm-project?rev=238630view=rev
Log:
Fix 80-column violations.
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=238630r1=238629r2=238630view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri May 29 18:09:49 2015
@@ -826,7 +826,8 @@ ABIArgInfo X86_32ABIInfo::getIndirectRet
return ABIArgInfo::getIndirect(/*Align=*/0, /*ByVal=*/false);
}
-ABIArgInfo X86_32ABIInfo::classifyReturnType(QualType RetTy, CCState State)
const {
+ABIArgInfo X86_32ABIInfo::classifyReturnType(QualType RetTy,
+ CCState State) const {
if (RetTy-isVoidType())
return ABIArgInfo::getIgnore();
@@ -1687,7 +1688,8 @@ static void addStackProbeSizeTargetAttri
if (CGM.getCodeGenOpts().StackProbeSize != 4096) {
llvm::Function *Fn = castllvm::Function(GV);
- Fn-addFnAttr(stack-probe-size,
llvm::utostr(CGM.getCodeGenOpts().StackProbeSize));
+ Fn-addFnAttr(stack-probe-size,
+llvm::utostr(CGM.getCodeGenOpts().StackProbeSize));
}
}
}
@@ -2847,7 +2849,7 @@ llvm::Value *X86_64ABIInfo::EmitVAArg(ll
unsigned neededInt, neededSSE;
Ty = CGF.getContext().getCanonicalType(Ty);
- ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE,
+ ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE,
/*isNamedArg*/false);
// AMD64-ABI 3.5.7p5: Step 1. Determine whether type may be passed
@@ -3126,7 +3128,8 @@ public:
class PPC32TargetCodeGenInfo : public TargetCodeGenInfo {
public:
- PPC32TargetCodeGenInfo(CodeGenTypes CGT) : TargetCodeGenInfo(new
PPC32_SVR4_ABIInfo(CGT)) {}
+ PPC32TargetCodeGenInfo(CodeGenTypes CGT)
+ : TargetCodeGenInfo(new PPC32_SVR4_ABIInfo(CGT)) {}
int getDwarfEHStackPointer(CodeGen::CodeGenModule M) const override {
// This is recovered from gcc output.
@@ -3153,19 +3156,25 @@ llvm::Value *PPC32_SVR4_ABIInfo::EmitVAA
}
bool isI64 = Ty-isIntegerType() getContext().getTypeSize(Ty) == 64;
- bool isInt = Ty-isIntegerType() || Ty-isPointerType() ||
Ty-isAggregateType();
+ bool isInt =
+ Ty-isIntegerType() || Ty-isPointerType() || Ty-isAggregateType();
llvm::Type *CharPtr = CGF.Int8PtrTy;
llvm::Type *CharPtrPtr = CGF.Int8PtrPtrTy;
CGBuilderTy Builder = CGF.Builder;
llvm::Value *GPRPtr = Builder.CreateBitCast(VAListAddr, CharPtr, gprptr);
llvm::Value *GPRPtrAsInt = Builder.CreatePtrToInt(GPRPtr, CGF.Int32Ty);
- llvm::Value *FPRPtrAsInt = Builder.CreateAdd(GPRPtrAsInt,
Builder.getInt32(1));
+ llvm::Value *FPRPtrAsInt =
+ Builder.CreateAdd(GPRPtrAsInt, Builder.getInt32(1));
llvm::Value *FPRPtr = Builder.CreateIntToPtr(FPRPtrAsInt, CharPtr);
- llvm::Value *OverflowAreaPtrAsInt = Builder.CreateAdd(FPRPtrAsInt,
Builder.getInt32(3));
- llvm::Value *OverflowAreaPtr = Builder.CreateIntToPtr(OverflowAreaPtrAsInt,
CharPtrPtr);
- llvm::Value *RegsaveAreaPtrAsInt = Builder.CreateAdd(OverflowAreaPtrAsInt,
Builder.getInt32(4));
- llvm::Value *RegsaveAreaPtr = Builder.CreateIntToPtr(RegsaveAreaPtrAsInt,
CharPtrPtr);
+ llvm::Value *OverflowAreaPtrAsInt =
+ Builder.CreateAdd(FPRPtrAsInt, Builder.getInt32(3));
+ llvm::Value *OverflowAreaPtr =
+ Builder.CreateIntToPtr(OverflowAreaPtrAsInt, CharPtrPtr);
+ llvm::Value *RegsaveAreaPtrAsInt =
+ Builder.CreateAdd(OverflowAreaPtrAsInt, Builder.getInt32(4));
+ llvm::Value *RegsaveAreaPtr =
+ Builder.CreateIntToPtr(RegsaveAreaPtrAsInt, CharPtrPtr);
llvm::Value *GPR = Builder.CreateLoad(GPRPtr, false, gpr);
// Align GPR when TY is i64.
if (isI64) {
@@ -3175,18 +3184,23 @@ llvm::Value *PPC32_SVR4_ABIInfo::EmitVAA
GPR = Builder.CreateSelect(CC64, GPRPlusOne, GPR);
}
llvm::Value *FPR = Builder.CreateLoad(FPRPtr, false, fpr);
- llvm::Value *OverflowArea = Builder.CreateLoad(OverflowAreaPtr, false,
overflow_area);
- llvm::Value *OverflowAreaAsInt = Builder.CreatePtrToInt(OverflowArea,
CGF.Int32Ty);
- llvm::Value *RegsaveArea = Builder.CreateLoad(RegsaveAreaPtr, false,
regsave_area);
- llvm::Value *RegsaveAreaAsInt = Builder.CreatePtrToInt(RegsaveArea,
CGF.Int32Ty);
+ llvm::Value *OverflowArea =
+ Builder.CreateLoad(OverflowAreaPtr, false, overflow_area);
+ llvm::Value *OverflowAreaAsInt =
+ Builder.CreatePtrToInt(OverflowArea, CGF.Int32Ty);
+ llvm::Value *RegsaveArea =
+ Builder.CreateLoad(RegsaveAreaPtr, false, regsave_area);
+ llvm::Value *RegsaveAreaAsInt =
+ Builder.CreatePtrToInt(RegsaveArea, CGF.Int32Ty);
- llvm::Value *CC = Builder.CreateICmpULT(isInt ? GPR : FPR,
- Builder.getInt8(8), cond);
+
Re: [PATCH] Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
Is there any reason not to purpose the existing option for this? Maybe do some archaeology to find out who added it and ask if it's fine to make it just start with the module? -eric http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Set function entry count.
As we commented in IRC this isn't going to be the correct way to do it. I've updated the PR accordingly and we should go ahead with that solution. Probably want to close this revision. Thanks! -eric http://reviews.llvm.org/D10035 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [Patch] Temporarily revert test to prepare for LLVM -fprofile-instr-generate= fix
Should just commit quickly. No worries about a breakage of a few minutes.
On Tue, May 12, 2015, 1:53 PM Teresa Johnson tejohn...@google.com wrote:
Hi echristo, bogner,
I apparently forgot to update the clang and llvm patches before
they were committed for me with the new name of the compiler-rt library
supporting -fprofile-instr-generate=, which was changed during the review
process. This wasn't caught by this test as it doesn't link and is
consistent
with the library call being inserted by llvm.
I want to temporarily revert this test so that it doesn't break when I make
the llvm change to call the correct library routine
(__llvm_profile_override_default_filename), then will send a patch to add
itx
back with the correct name.
Tested via ninja clang-test
http://reviews.llvm.org/D9717
Files:
test/Profile/c-generate.c
Index: test/Profile/c-generate.c
===
--- test/Profile/c-generate.c
+++ /dev/null
@@ -1,10 +0,0 @@
-// Check that the -fprofile-instr-generate= form works.
-// RUN: %clang_cc1 -main-file-name c-generate.c %s -o - -emit-llvm
-fprofile-instr-generate=c-generate-test.profraw | FileCheck %s
-
-// CHECK: private constant [24 x i8] cc-generate-test.profraw\00
-// CHECK: call void @__llvm_profile_set_filename_env_override(i8*
getelementptr inbounds ([24 x i8], [24 x i8]* @0, i32 0, i32 0))
-// CHECK: declare void @__llvm_profile_set_filename_env_override(i8*)
-
-int main(void) {
- return 0;
-}
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r237071 - Update initialization of a class variable and comment.
Author: echristo
Date: Mon May 11 19:04:20 2015
New Revision: 237071
URL: http://llvm.org/viewvc/llvm-project?rev=237071view=rev
Log:
Update initialization of a class variable and comment.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=237071r1=237070r2=237071view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon May 11 19:04:20 2015
@@ -5349,11 +5349,13 @@ class SparcTargetInfo : public TargetInf
static const char * const GCCRegNames[];
bool SoftFloat;
public:
- SparcTargetInfo(const llvm::Triple Triple) : TargetInfo(Triple) {}
+ SparcTargetInfo(const llvm::Triple Triple)
+ : TargetInfo(Triple), SoftFloat(false) {}
bool handleTargetFeatures(std::vectorstd::string Features,
DiagnosticsEngine Diags) override {
-SoftFloat = false;
+// The backend doesn't actually handle soft float yet, but in case someone
+// is using the support for the front end continue to support it.
auto Feature = std::find(Features.begin(), Features.end(), +soft-float);
if (Feature != Features.end()) {
SoftFloat = true;
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r237080 - Remove the code that pulled soft float attributes out of the feature
Author: echristo
Date: Mon May 11 20:26:21 2015
New Revision: 237080
URL: http://llvm.org/viewvc/llvm-project?rev=237080view=rev
Log:
Remove the code that pulled soft float attributes out of the feature
strings and remove the setting of TargetOptions::UseSoftFloat to
match the code change in llvm r237079.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/function-target-features.c
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=237080r1=237079r2=237080view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon May 11 20:26:21 2015
@@ -4271,12 +4271,10 @@ public:
Features.push_back(-neonfp);
// Remove front-end specific options which the backend handles differently.
-const StringRef FrontEndFeatures[] = { +soft-float, +soft-float-abi };
-for (const auto FEFeature : FrontEndFeatures) {
- auto Feature = std::find(Features.begin(), Features.end(), FEFeature);
- if (Feature != Features.end())
-Features.erase(Feature);
-}
+auto Feature =
+std::find(Features.begin(), Features.end(), +soft-float-abi);
+if (Feature != Features.end())
+ Features.erase(Feature);
return true;
}
@@ -6149,12 +6147,6 @@ public:
IsNan2008 = false;
}
-// Remove front-end specific options.
-std::vectorstd::string::iterator it =
- std::find(Features.begin(), Features.end(), +soft-float);
-if (it != Features.end())
- Features.erase(it);
-
setDescriptionString();
return true;
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=237080r1=237079r2=237080view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon May 11 20:26:21 2015
@@ -531,7 +531,6 @@ TargetMachine *EmitAssemblyHelper::Creat
Options.NoNaNsFPMath = CodeGenOpts.NoNaNsFPMath;
Options.NoZerosInBSS = CodeGenOpts.NoZeroInitializedInBSS;
Options.UnsafeFPMath = CodeGenOpts.UnsafeFPMath;
- Options.UseSoftFloat = CodeGenOpts.SoftFloat;
Options.StackAlignmentOverride = CodeGenOpts.StackAlignment;
Options.DisableTailCalls = CodeGenOpts.DisableTailCalls;
Options.TrapFuncName = CodeGenOpts.TrapFuncName;
Modified: cfe/trunk/test/CodeGen/function-target-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/function-target-features.c?rev=237080r1=237079r2=237080view=diff
==
--- cfe/trunk/test/CodeGen/function-target-features.c (original)
+++ cfe/trunk/test/CodeGen/function-target-features.c Mon May 11 20:26:21 2015
@@ -9,7 +9,7 @@
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s
-target-cpu corei7 -target-feature +avx | FileCheck %s
-check-prefix=CORE-CPU-AND-FEATURES
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s
-target-cpu x86-64 | FileCheck %s -check-prefix=X86-64-CPU
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s
-target-cpu corei7-avx -target-feature -avx | FileCheck %s
-check-prefix=AVX-MINUS-FEATURE
-// RUN: %clang_cc1 -triple sparc-unknown-unknown -emit-llvm -o - %s
-target-feature +soft-float | FileCheck %s -check-prefix=SOFT-FLOAT
+// RUN: %clang_cc1 -triple sparc-unknown-unknown -emit-llvm -o - %s
-target-feature +soft-float | FileCheck %s -check-prefix=NO-SOFT-FLOAT
// RUN: %clang_cc1 -triple arm-unknown-unknown -emit-llvm -o - %s
-target-feature +soft-float | FileCheck %s -check-prefix=SOFT-FLOAT
// RUN: %clang_cc1 -triple mips-unknown-unknown -emit-llvm -o - %s
-target-feature +soft-float | FileCheck %s -check-prefix=SOFT-FLOAT
@@ -22,4 +22,5 @@ void foo() {}
// CORE-CPU-AND-FEATURES: target-cpu=corei7 target-features={{.*}}+avx
// X86-64-CPU: target-cpu=x86-64
// AVX-MINUS-FEATURE: target-features={{.*}}-avx
-// SOFT-FLOAT-NOT: target-features={{.*}}+soft-float
+// SOFT-FLOAT: target-features={{.*}}+soft-float
+// NO-SOFT-FLOAT-NOT: target-features={{.*}}+soft-float
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [cuda] Include GPU binary into host object file and generate init/deinit code.
Yeah, we don't really want to run the verifier on every compile. Very slow. :) -eric Comment at: lib/CodeGen/CGCUDANV.cpp:23 @@ -22,3 +22,3 @@ #include llvm/IR/DerivedTypes.h -#include vector +#include llvm/IR/Verifier.h We don't actually want to run the verifier on every compilation :) http://reviews.llvm.org/D9507 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
