RE: r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list
Adding Ziv, the author of this patch.
From: Chandler Carruth [mailto:chandl...@google.com]
Sent: Thursday, December 29, 2016 11:57
To: Yatsina, Marina ; cfe-commits@lists.llvm.org
Subject: Re: r290539 - [inline-asm]No error for conflict between inputs\outputs
and clobber list
On Mon, Dec 26, 2016 at 4:34 AM Marina Yatsina via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: myatsina
Date: Mon Dec 26 06:23:42 2016
New Revision: 290539
URL: http://llvm.org/viewvc/llvm-project?rev=290539&view=rev
Log:
[inline-asm]No error for conflict between inputs\outputs and clobber list
According to extended asm syntax, a case where the clobber list includes a
variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st
aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/lib/Basic/TargetInfo.cpp
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Headers/intrin.h
cfe/trunk/lib/Sema/SemaStmtAsm.cpp
cfe/trunk/test/Sema/asm.c
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290539&r1=290538&r2=290539&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 26 06:23:42
2016
@@ -7069,6 +7069,10 @@ let CategoryName = "Inline Assembly Issu
"constraint '%0' is already present here">;
}
+ def error_inoutput_conflict_with_clobber : Error<
+"asm-specifier for input or output variable conflicts with asm"
+" clobber list">;
Clang generally works to avoid this kind of error message. All this does is say
"there was a problem of this kind" without identifying any of the specifics.
And for this error in particular I think this is of the utmost importance.
Developers are not going to understand what went wrong here.
I would suggest at a minimum to enhance this to explain:
1) What operands and clobbers conflict, preferably with source ranges
underlining them.
2) Why they conflict (for example the fact that "D" means the di register
group, of which "%rdi" is a member)
Beyond that, I wonder if you could add a note suggesting to remove the clobber
if the input (or output) operand is sufficient.
You can make this note explain carefully the case where something would need to
be added to the inputs or outputs instead, but I think it at least makes sense
to clarify that this will be a common fix and what to look out for that might
make it an incorrect fix.
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: r278783 - [X86] Add xgetbv/x[X86] Add xgetbv xsetbv intrinsics to non-windows platforms
Adding Guy, the author of this commit.
From: Reid Kleckner [mailto:r...@google.com]
Sent: Tuesday, August 16, 2016 19:14
To: Yatsina, Marina
Cc: cfe-commits
Subject: Re: r278783 - [X86] Add xgetbv/x[X86] Add xgetbv xsetbv intrinsics to
non-windows platforms
Reverted in r278814, it appears to break usage of _xgetbv on Windows:
https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin%28dll%29/builds/5846/steps/compile/logs/stdio
../../base/cpu.cc(194,10): error: use of undeclared identifier '_xgetbv'
(_xgetbv(0) & 6) == 6 /* XSAVE enabled by kernel */;
You removed the test in ms-intrin.cpp that would have prevented this breakage,
too.
On Tue, Aug 16, 2016 at 1:13 AM, Marina Yatsina via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: myatsina
Date: Tue Aug 16 03:13:36 2016
New Revision: 278783
URL: http://llvm.org/viewvc/llvm-project?rev=278783&view=rev
Log:
[X86] Add xgetbv/x[X86] Add xgetbv xsetbv intrinsics to non-windows platforms
commit on behalf of guyblank
Differential Revision: https://reviews.llvm.org/D21959
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/intrin.h
cfe/trunk/lib/Headers/xsaveintrin.h
cfe/trunk/test/CodeGen/builtins-x86.c
cfe/trunk/test/CodeGen/x86_32-xsave.c
cfe/trunk/test/CodeGen/x86_64-xsave.c
cfe/trunk/test/Headers/ms-intrin.cpp
Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=278783&r1=278782&r2=278783&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Tue Aug 16 03:13:36 2016
@@ -644,6 +644,8 @@ TARGET_BUILTIN(__builtin_ia32_fxsave64,
// XSAVE
TARGET_BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "", "xsave")
TARGET_BUILTIN(__builtin_ia32_xsave64, "vv*ULLi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xgetbv, "ULLiUi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xsetbv, "vUiULLi", "", "xsave")
TARGET_BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "", "xsave")
TARGET_BUILTIN(__builtin_ia32_xrstor64, "vv*ULLi", "", "xsave")
TARGET_BUILTIN(__builtin_ia32_xsaveopt, "vv*ULLi", "", "xsaveopt")
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=278783&r1=278782&r2=278783&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Aug 16 03:13:36 2016
@@ -6915,7 +6915,8 @@ Value *CodeGenFunction::EmitX86BuiltinEx
case X86::BI__builtin_ia32_xsavec:
case X86::BI__builtin_ia32_xsavec64:
case X86::BI__builtin_ia32_xsaves:
- case X86::BI__builtin_ia32_xsaves64: {
+ case X86::BI__builtin_ia32_xsaves64:
+ case X86::BI__builtin_ia32_xsetbv: {
Intrinsic::ID ID;
#define INTRINSIC_X86_XSAVE_ID(NAME) \
case X86::BI__builtin_ia32_##NAME: \
@@ -6935,6 +6936,7 @@ Value *CodeGenFunction::EmitX86BuiltinEx
INTRINSIC_X86_XSAVE_ID(xsavec64);
INTRINSIC_X86_XSAVE_ID(xsaves);
INTRINSIC_X86_XSAVE_ID(xsaves64);
+INTRINSIC_X86_XSAVE_ID(xsetbv);
}
#undef INTRINSIC_X86_XSAVE_ID
Value *Mhi = Builder.CreateTrunc(
@@ -6944,6 +6946,8 @@ Value *CodeGenFunction::EmitX86BuiltinEx
Ops.push_back(Mlo);
return Builder.CreateCall(CGM.getIntrinsic(ID), Ops);
}
+ case X86::BI__builtin_ia32_xgetbv:
+return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::x86_xgetbv), Ops);
case X86::BI__builtin_ia32_storedqudi128_mask:
case X86::BI__builtin_ia32_storedqusi128_mask:
case X86::BI__builtin_ia32_storedquhi128_mask:
Modified: cfe/trunk/lib/Headers/intrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/intrin.h?rev=278783&r1=278782&r2=278783&view=diff
==
--- cfe/trunk/lib/Headers/intrin.h (original)
+++ cfe/trunk/lib/Headers/intrin.h Tue Aug 16 03:13:36 2016
@@ -289,10 +289,6 @@ static __inline__
void _WriteBarrier(void);
unsigned __int32 xbegin(void);
void _xend(void);
-static __inline__
-#define _XCR_XFEATURE_ENABLED_MASK 0
-unsigned __int64 __cdecl _xgetbv(unsigned int);
-void __cdecl _xsetbv(unsigned int, unsigned __int64);
/* These additional intrinsics are turned on in x64/amd64/x86_64 mode. */
#ifdef __x86_64__
@@ -908,12 +904,6 @@ __cpuidex(int __info[4], int __level, in
__asm__ ("cpuid" : "=a"(__info[0]), "=b" (__info[1]), "=c"(__info[2]),
"=d"(__info[3])
: "a"(__level), "c"(__ecx));
}
-static __inline__ unsigned __int64 __cdecl __DEFAULT_FN_ATTRS
-_xgetbv(unsigned int __xcr_no) {
- unsigned int __eax, __edx;
- __asm__ ("xgetbv" : "=a" (__eax), "=d" (__edx) : "c" (__xcr_no));
- return ((unsigned __int64)__edx << 32) | __eax;
-}
static __inline__
RE: r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list
It should.
Ziv, there seems to be some bug with the implementation, can you fix it please?
Thanks,
Marina
-Original Message-
From: Dimitry Andric [mailto:dimi...@andric.com]
Sent: Tuesday, January 31, 2017 22:39
To: Yatsina, Marina
Cc: cfe-commits ; Izhar, Ziv
Subject: Re: r290539 - [inline-asm]No error for conflict between inputs\outputs
and clobber list
On 26 Dec 2016, at 13:23, Marina Yatsina via cfe-commits
wrote:
>
> Author: myatsina
> Date: Mon Dec 26 06:23:42 2016
> New Revision: 290539
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290539&view=rev
> Log:
> [inline-asm]No error for conflict between inputs\outputs and clobber
> list
>
> According to extended asm syntax, a case where the clobber list includes a
> variable from the inputs or outputs should be an error - conflict.
> for example:
>
> const long double a = 0.0;
> int main()
> {
>
> char b;
> double t1 = a;
> __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st",
> "st(1)");
>
> return 0;
> }
>
> This should conflict with the output - t1 which is st, and st which is st
> aswell.
In FreeBSD ports, we are now getting this new error message when compiling
svgalib (see https://bugs.freebsd.org/216154), when compiling with clang 4.0.0.
While fixing it, we noticed something strange (or interesting, depending on
your point of view), namely that it does not seem to handle the first input or
output operand, e.g. "0". For example, svgalib has this inline function:
/* Always 32-bit align destination, even for a small number of bytes. */ static
inline void * __memcpy_aligndest(void *dest, const void *src, int n) {
__asm__ __volatile__("cmpl $3, %%ecx\n\t"
"ja 1f\n\t"
"call * __memcpy_jumptable (, %%ecx, 4)\n\t"
"jmp 2f\n\t"
"1:call __memcpyasm_regargs\n\t"
"2:":
:"S"(dest), "d"(src), "c"(n)
:"ax", "0", "1", "2");
return dest;
}
The error produced for this is:
svgalib-1.4.3/gl/inlstring.h:281:17: error: asm-specifier for input or output
variable conflicts with asm clobber list
:"ax", "0", "1", "2");
^
And indeed, removing the "1" and "2" input operands fixes the error. However,
by definition, "0" is always an input or output operand, so should it not
produce an error too?
-Dimitry
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
