[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

> What exactly does it mean for a constraint to conflict with a feature? The 
> only thing I can think of is if it somehow involves a register class that 
> doesn't exist on the target with the current set of target features. I guess 
> we could try to diagnose that, but I'm not sure it's worth duplicating that 
> code.

Yes, indeed. For instance, we have a constraint `x` that must provide `xmm` 
register. But if we compile with `-mno-sse` there are no `xmm`s available. And 
these changes in targets are the prework to handle these cases in clang. This 
is not a special case for X86. ARM, for example, makes some target constraints 
invalid if a feature is not enabled:
https://github.com/llvm/llvm-project/blob/a9c12e481bfef5b2913e2241486f4dd450188cd2/clang/lib/Basic/Targets/ARM.cpp#L1157-L1161

However this implementation is buggy because it doesn't consider function 
attributes. In case of multiversioning in the same TU we will hit compilation 
errors.

>  I'm not sure it's worth duplicating that code.

So, then return to the idea to better diagnose these things from backends?

https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

> I think the specific checks clang is doing here have to be part of clang: in 
> particular, clang needs to translate from gcc syntax to LLVM IR asm syntax, 
> and that requires parsing the constraints. So these checks are necessary, and 
> emitting better diagnostics for checks we need to do anyway seems fine.

Yes. But constraints are checked. The problem here is that they may conflict 
with features. Should this "features+constraint" combination checked in the 
frontend or in the backend?

I like the idea of checking it in the frontend because we may point to the 
specific constraint. In the backend we can point only to the whole expression 
or even emit a generic error without a line.

https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud updated https://github.com/llvm/llvm-project/pull/96363

>From 4f8504878da33925609d52912e8d0e1f64c41066 Mon Sep 17 00:00:00 2001
From: Evgenii Kudriashov 
Date: Fri, 21 Jun 2024 14:00:58 -0700
Subject: [PATCH 1/3] [clang] Improve diagnostics for constraints of inline asm

Introduce more detailed diagnostics for the constrains. Also provide an
opportunity for backends to provide detailed diagnostics for target
specific constraints based on enabled features.
---
 .../clang/Basic/DiagnosticCommonKinds.td  | 33 +
 .../clang/Basic/DiagnosticSemaKinds.td|  4 --
 clang/include/clang/Basic/TargetInfo.h| 19 +++--
 clang/lib/Basic/TargetInfo.cpp| 63 +++-
 clang/lib/Basic/Targets/AArch64.cpp   |  6 +-
 clang/lib/Basic/Targets/AArch64.h |  4 +-
 clang/lib/Basic/Targets/AMDGPU.h  |  7 +-
 clang/lib/Basic/Targets/ARC.h |  4 +-
 clang/lib/Basic/Targets/ARM.cpp   |  6 +-
 clang/lib/Basic/Targets/ARM.h |  4 +-
 clang/lib/Basic/Targets/AVR.h |  4 +-
 clang/lib/Basic/Targets/BPF.h |  4 +-
 clang/lib/Basic/Targets/CSKY.cpp  |  6 +-
 clang/lib/Basic/Targets/CSKY.h|  4 +-
 clang/lib/Basic/Targets/DirectX.h |  4 +-
 clang/lib/Basic/Targets/Hexagon.h |  4 +-
 clang/lib/Basic/Targets/Lanai.h   |  4 +-
 clang/lib/Basic/Targets/Le64.h|  4 +-
 clang/lib/Basic/Targets/LoongArch.cpp |  3 +-
 clang/lib/Basic/Targets/LoongArch.h   |  4 +-
 clang/lib/Basic/Targets/M68k.cpp  | 30 
 clang/lib/Basic/Targets/M68k.h|  4 +-
 clang/lib/Basic/Targets/MSP430.h  |  4 +-
 clang/lib/Basic/Targets/Mips.h|  4 +-
 clang/lib/Basic/Targets/NVPTX.h   |  4 +-
 clang/lib/Basic/Targets/PNaCl.h   |  4 +-
 clang/lib/Basic/Targets/PPC.h |  4 +-
 clang/lib/Basic/Targets/RISCV.cpp |  6 +-
 clang/lib/Basic/Targets/RISCV.h   |  4 +-
 clang/lib/Basic/Targets/SPIR.cpp  |  5 +-
 clang/lib/Basic/Targets/SPIR.h|  8 ++-
 clang/lib/Basic/Targets/Sparc.h   |  6 +-
 clang/lib/Basic/Targets/SystemZ.cpp   |  6 +-
 clang/lib/Basic/Targets/SystemZ.h |  4 +-
 clang/lib/Basic/Targets/TCE.h |  4 +-
 clang/lib/Basic/Targets/VE.h  |  4 +-
 clang/lib/Basic/Targets/WebAssembly.h |  4 +-
 clang/lib/Basic/Targets/X86.cpp   |  6 +-
 clang/lib/Basic/Targets/X86.h |  4 +-
 clang/lib/Basic/Targets/XCore.h   |  4 +-
 clang/lib/CodeGen/CGStmt.cpp  | 21 --
 clang/lib/Sema/SemaStmtAsm.cpp| 18 ++---
 clang/test/Sema/asm.c | 72 ++-
 43 files changed, 287 insertions(+), 134 deletions(-)

diff --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index de758cbe679dc..d4b0862337165 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -309,6 +309,39 @@ def err_asm_invalid_type : Error<
 def err_ms_asm_bitfield_unsupported : Error<
   "an inline asm block cannot have an operand which is a bit-field">;
 
+def asm_invalid_constraint_generic : TextSubstitution<
+  "invalid %select{input|output}0 constraint '%1' in asm">;
+def err_asm_invalid_constraint : Error<
+  "%sub{asm_invalid_constraint_generic}0,1">;
+def err_asm_invalid_constraint_start : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: output constraint must start with"
+  " '=' or '+'">;
+def err_asm_invalid_constraint_rw_clobber : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: early clobber with a read-write"
+  " constraint must be a register">;
+def err_asm_invalid_constraint_mem_or_reg : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: constraint must allow either"
+  " memory or register operands">;
+def err_asm_invalid_constraint_missing_bracket : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: missing ']'">;
+def err_asm_invalid_constraint_wrong_symbol : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: cannot find an output constraint"
+  " with the specified name">;
+def err_asm_invalid_constraint_empty : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: empty constraint has been"
+  " provided">;
+def err_asm_invalid_constraint_oob : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: the index is out of bounds">;
+def err_asm_invalid_constraint_missing : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: references to a non-existing 
output"
+  " constraint">;
+def err_asm_invalid_constraint_wrongly_tied : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: tied constraint must be tied to"
+  " the same operand referenced to by the number">;
+def 

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud updated https://github.com/llvm/llvm-project/pull/96363

>From 4f8504878da33925609d52912e8d0e1f64c41066 Mon Sep 17 00:00:00 2001
From: Evgenii Kudriashov 
Date: Fri, 21 Jun 2024 14:00:58 -0700
Subject: [PATCH 1/2] [clang] Improve diagnostics for constraints of inline asm

Introduce more detailed diagnostics for the constrains. Also provide an
opportunity for backends to provide detailed diagnostics for target
specific constraints based on enabled features.
---
 .../clang/Basic/DiagnosticCommonKinds.td  | 33 +
 .../clang/Basic/DiagnosticSemaKinds.td|  4 --
 clang/include/clang/Basic/TargetInfo.h| 19 +++--
 clang/lib/Basic/TargetInfo.cpp| 63 +++-
 clang/lib/Basic/Targets/AArch64.cpp   |  6 +-
 clang/lib/Basic/Targets/AArch64.h |  4 +-
 clang/lib/Basic/Targets/AMDGPU.h  |  7 +-
 clang/lib/Basic/Targets/ARC.h |  4 +-
 clang/lib/Basic/Targets/ARM.cpp   |  6 +-
 clang/lib/Basic/Targets/ARM.h |  4 +-
 clang/lib/Basic/Targets/AVR.h |  4 +-
 clang/lib/Basic/Targets/BPF.h |  4 +-
 clang/lib/Basic/Targets/CSKY.cpp  |  6 +-
 clang/lib/Basic/Targets/CSKY.h|  4 +-
 clang/lib/Basic/Targets/DirectX.h |  4 +-
 clang/lib/Basic/Targets/Hexagon.h |  4 +-
 clang/lib/Basic/Targets/Lanai.h   |  4 +-
 clang/lib/Basic/Targets/Le64.h|  4 +-
 clang/lib/Basic/Targets/LoongArch.cpp |  3 +-
 clang/lib/Basic/Targets/LoongArch.h   |  4 +-
 clang/lib/Basic/Targets/M68k.cpp  | 30 
 clang/lib/Basic/Targets/M68k.h|  4 +-
 clang/lib/Basic/Targets/MSP430.h  |  4 +-
 clang/lib/Basic/Targets/Mips.h|  4 +-
 clang/lib/Basic/Targets/NVPTX.h   |  4 +-
 clang/lib/Basic/Targets/PNaCl.h   |  4 +-
 clang/lib/Basic/Targets/PPC.h |  4 +-
 clang/lib/Basic/Targets/RISCV.cpp |  6 +-
 clang/lib/Basic/Targets/RISCV.h   |  4 +-
 clang/lib/Basic/Targets/SPIR.cpp  |  5 +-
 clang/lib/Basic/Targets/SPIR.h|  8 ++-
 clang/lib/Basic/Targets/Sparc.h   |  6 +-
 clang/lib/Basic/Targets/SystemZ.cpp   |  6 +-
 clang/lib/Basic/Targets/SystemZ.h |  4 +-
 clang/lib/Basic/Targets/TCE.h |  4 +-
 clang/lib/Basic/Targets/VE.h  |  4 +-
 clang/lib/Basic/Targets/WebAssembly.h |  4 +-
 clang/lib/Basic/Targets/X86.cpp   |  6 +-
 clang/lib/Basic/Targets/X86.h |  4 +-
 clang/lib/Basic/Targets/XCore.h   |  4 +-
 clang/lib/CodeGen/CGStmt.cpp  | 21 --
 clang/lib/Sema/SemaStmtAsm.cpp| 18 ++---
 clang/test/Sema/asm.c | 72 ++-
 43 files changed, 287 insertions(+), 134 deletions(-)

diff --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index de758cbe679dc..d4b0862337165 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -309,6 +309,39 @@ def err_asm_invalid_type : Error<
 def err_ms_asm_bitfield_unsupported : Error<
   "an inline asm block cannot have an operand which is a bit-field">;
 
+def asm_invalid_constraint_generic : TextSubstitution<
+  "invalid %select{input|output}0 constraint '%1' in asm">;
+def err_asm_invalid_constraint : Error<
+  "%sub{asm_invalid_constraint_generic}0,1">;
+def err_asm_invalid_constraint_start : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: output constraint must start with"
+  " '=' or '+'">;
+def err_asm_invalid_constraint_rw_clobber : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: early clobber with a read-write"
+  " constraint must be a register">;
+def err_asm_invalid_constraint_mem_or_reg : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: constraint must allow either"
+  " memory or register operands">;
+def err_asm_invalid_constraint_missing_bracket : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: missing ']'">;
+def err_asm_invalid_constraint_wrong_symbol : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: cannot find an output constraint"
+  " with the specified name">;
+def err_asm_invalid_constraint_empty : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: empty constraint has been"
+  " provided">;
+def err_asm_invalid_constraint_oob : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: the index is out of bounds">;
+def err_asm_invalid_constraint_missing : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: references to a non-existing 
output"
+  " constraint">;
+def err_asm_invalid_constraint_wrongly_tied : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: tied constraint must be tied to"
+  " the same operand referenced to by the number">;
+def 

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

@@ -309,6 +309,39 @@ def err_asm_invalid_type : Error<
 def err_ms_asm_bitfield_unsupported : Error<
   "an inline asm block cannot have an operand which is a bit-field">;
 
+def asm_invalid_constraint_generic : TextSubstitution<
+  "invalid %select{input|output}0 constraint '%1' in asm">;
+def err_asm_invalid_constraint : Error<
+  "%sub{asm_invalid_constraint_generic}0,1">;
+def err_asm_invalid_constraint_start : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: output constraint must start with"
+  " '=' or '+'">;
+def err_asm_invalid_constraint_rw_clobber : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: early clobber with a read-write"
+  " constraint must be a register">;
+def err_asm_invalid_constraint_mem_or_reg : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: constraint must allow either"
+  " memory or register operands">;
+def err_asm_invalid_constraint_missing_bracket : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: missing ']'">;
+def err_asm_invalid_constraint_wrong_symbol : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: cannot find an output constraint"
+  " with the specified name">;

e-kud wrote:

Yes, this is similar to digits
> Input constraints can also be digits (for example, "0"). This indicates that 
> the specified input must be in the same place as the output constraint at the 
> (zero-based) index in the output constraint list. When using asmSymbolicName 
> syntax for the output operands, you may use these names (enclosed in brackets 
> []) instead of digits.

https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

So, I think this PR still makes sense but without target changes, right?

I've taken a look at the backend and constraints are checked in 
`getRegForInlineAsmConstraint`. We either need to return an error message or 
pass `Context` into it. The former is preferrable because a call of 
`getRegForInlineAsmConstraint` doesn't always mean an error is requried. 
However, in both cases we need to touch all the targets...

https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

> It's really unfortunate to have to add all this asm handling to clang. Can't 
> it rely on backend diagnostic remarks for this?

I've tried to do the similar thing in the backend: 
https://reviews.llvm.org/D152332. The problem I see is that `llc`'s error 
handler ignores errors and continues compilation until something further 
reports a fatal error. In other words we have to return something wrong 
intentionally to continue compilation. On the other hand, we can prepare all 
callers to have an error somewhere inside but there will be a lot of refactor 
because there is no common practice to emit target specific errors. 
`report_fatal_error` is more likable.

```
$ grep -R emitError lib/Target/X86/*
lib/Target/X86/X86FloatingPoint.cpp:  MI.emitError("fixed input regs must 
be last on the x87 stack");
lib/Target/X86/X86FloatingPoint.cpp:  MI.emitError("output regs must be 
last on the x87 stack");
lib/Target/X86/X86FloatingPoint.cpp:  MI.emitError("clobbers must be last 
on the x87 stack");
lib/Target/X86/X86FloatingPoint.cpp:  MI.emitError("implicitly popped regs 
must be last on the x87 stack");
lib/Target/X86/X86PreTileConfig.cpp:static void emitErrorMsg(MachineFunction 
) {
lib/Target/X86/X86PreTileConfig.cpp:  Context.emitError(
lib/Target/X86/X86PreTileConfig.cpp:  emitErrorMsg(MF);
lib/Target/X86/X86PreTileConfig.cpp:  emitErrorMsg(MF);
$ grep -R emitError lib/Target/AArch64/*
lib/Target/AArch64/AArch64AsmPrinter.cpp:BaseGV->getContext().emitError(
$ grep -R emitError lib/Target/RISCV/*
$
```
```
$ grep -R emitError lib/Target/* | wc -l
47
$ grep -R report_fatal_error lib/Target/* | wc -l
675
```
I'm not sure whether it is much better. 



https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

Initially I've implemented the target errors through std::string. Then changed 
to diag::kind after reading InternalsManual. I'm not sure what is better. The 
drawback of returning diagnoistics by reference is that we can't customize 
them, only fixed messages. Maybe this is not a big problem because we don't 
have constantly changing constraints. 

https://github.com/llvm/llvm-project/pull/96363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Improve diagnostics for constraints of inline asm (NFC) (PR #96363)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud created https://github.com/llvm/llvm-project/pull/96363

Introduce more detailed diagnostics for the constrains. Also provide an 
opportunity for backends to provide detailed diagnostics for target specific 
constraints based on enabled features. We provide features as a pointer 
intentionally because they are not available in some of existing uses. So 
backends need to consider whether features are available or not.

>From 4f8504878da33925609d52912e8d0e1f64c41066 Mon Sep 17 00:00:00 2001
From: Evgenii Kudriashov 
Date: Fri, 21 Jun 2024 14:00:58 -0700
Subject: [PATCH] [clang] Improve diagnostics for constraints of inline asm

Introduce more detailed diagnostics for the constrains. Also provide an
opportunity for backends to provide detailed diagnostics for target
specific constraints based on enabled features.
---
 .../clang/Basic/DiagnosticCommonKinds.td  | 33 +
 .../clang/Basic/DiagnosticSemaKinds.td|  4 --
 clang/include/clang/Basic/TargetInfo.h| 19 +++--
 clang/lib/Basic/TargetInfo.cpp| 63 +++-
 clang/lib/Basic/Targets/AArch64.cpp   |  6 +-
 clang/lib/Basic/Targets/AArch64.h |  4 +-
 clang/lib/Basic/Targets/AMDGPU.h  |  7 +-
 clang/lib/Basic/Targets/ARC.h |  4 +-
 clang/lib/Basic/Targets/ARM.cpp   |  6 +-
 clang/lib/Basic/Targets/ARM.h |  4 +-
 clang/lib/Basic/Targets/AVR.h |  4 +-
 clang/lib/Basic/Targets/BPF.h |  4 +-
 clang/lib/Basic/Targets/CSKY.cpp  |  6 +-
 clang/lib/Basic/Targets/CSKY.h|  4 +-
 clang/lib/Basic/Targets/DirectX.h |  4 +-
 clang/lib/Basic/Targets/Hexagon.h |  4 +-
 clang/lib/Basic/Targets/Lanai.h   |  4 +-
 clang/lib/Basic/Targets/Le64.h|  4 +-
 clang/lib/Basic/Targets/LoongArch.cpp |  3 +-
 clang/lib/Basic/Targets/LoongArch.h   |  4 +-
 clang/lib/Basic/Targets/M68k.cpp  | 30 
 clang/lib/Basic/Targets/M68k.h|  4 +-
 clang/lib/Basic/Targets/MSP430.h  |  4 +-
 clang/lib/Basic/Targets/Mips.h|  4 +-
 clang/lib/Basic/Targets/NVPTX.h   |  4 +-
 clang/lib/Basic/Targets/PNaCl.h   |  4 +-
 clang/lib/Basic/Targets/PPC.h |  4 +-
 clang/lib/Basic/Targets/RISCV.cpp |  6 +-
 clang/lib/Basic/Targets/RISCV.h   |  4 +-
 clang/lib/Basic/Targets/SPIR.cpp  |  5 +-
 clang/lib/Basic/Targets/SPIR.h|  8 ++-
 clang/lib/Basic/Targets/Sparc.h   |  6 +-
 clang/lib/Basic/Targets/SystemZ.cpp   |  6 +-
 clang/lib/Basic/Targets/SystemZ.h |  4 +-
 clang/lib/Basic/Targets/TCE.h |  4 +-
 clang/lib/Basic/Targets/VE.h  |  4 +-
 clang/lib/Basic/Targets/WebAssembly.h |  4 +-
 clang/lib/Basic/Targets/X86.cpp   |  6 +-
 clang/lib/Basic/Targets/X86.h |  4 +-
 clang/lib/Basic/Targets/XCore.h   |  4 +-
 clang/lib/CodeGen/CGStmt.cpp  | 21 --
 clang/lib/Sema/SemaStmtAsm.cpp| 18 ++---
 clang/test/Sema/asm.c | 72 ++-
 43 files changed, 287 insertions(+), 134 deletions(-)

diff --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index de758cbe679dc..d4b0862337165 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -309,6 +309,39 @@ def err_asm_invalid_type : Error<
 def err_ms_asm_bitfield_unsupported : Error<
   "an inline asm block cannot have an operand which is a bit-field">;
 
+def asm_invalid_constraint_generic : TextSubstitution<
+  "invalid %select{input|output}0 constraint '%1' in asm">;
+def err_asm_invalid_constraint : Error<
+  "%sub{asm_invalid_constraint_generic}0,1">;
+def err_asm_invalid_constraint_start : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: output constraint must start with"
+  " '=' or '+'">;
+def err_asm_invalid_constraint_rw_clobber : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: early clobber with a read-write"
+  " constraint must be a register">;
+def err_asm_invalid_constraint_mem_or_reg : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: constraint must allow either"
+  " memory or register operands">;
+def err_asm_invalid_constraint_missing_bracket : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: missing ']'">;
+def err_asm_invalid_constraint_wrong_symbol : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: cannot find an output constraint"
+  " with the specified name">;
+def err_asm_invalid_constraint_empty : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: empty constraint has been"
+  " provided">;
+def err_asm_invalid_constraint_oob : Error<
+  "%sub{asm_invalid_constraint_generic}0,1: the index is out of bounds">;

[lld] [llvm] [lldb] [libunwind] [compiler-rt] [clang] [flang] [clang-tools-extra] [mlir] [openmp] [BranchFolding] Fix missing predecessors of landing-pad (PR #77608)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[lld] [llvm] [lldb] [libunwind] [compiler-rt] [clang] [flang] [clang-tools-extra] [mlir] [openmp] [BranchFolding] Fix missing predecessors of landing-pad (PR #77608)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[lld] [llvm] [lldb] [libunwind] [compiler-rt] [clang] [flang] [clang-tools-extra] [mlir] [openmp] [BranchFolding] Fix missing predecessors of landing-pad (PR #77608)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [mlir] [compiler-rt] [libunwind] [flang] [lldb] [llvm] [clang-tools-extra] [openmp] [lld] [BranchFolding] Fix missing predecessors of landing-pad (PR #77608)

[Evgenii Kudriashov via cfe-commits]

@@ -0,0 +1,80 @@
+; RUN: llc -mtriple=x86_64-pc-windows-msvc %s

e-kud wrote:

It seems we still have this file on `avx512-intel64` worker:
https://lab.llvm.org/buildbot/#/builders/258/builds/12970
https://lab.llvm.org/buildbot/#/builders/258/builds/12971

https://github.com/llvm/llvm-project/pull/77608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [llvm] [clang] [X86][GlobalISel] Remove G_OR/G_AND/G_XOR test duplication (NFC) (PR #79088)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud closed https://github.com/llvm/llvm-project/pull/79088
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [llvm] [X86][GlobalISel] Remove G_OR/G_AND/G_XOR test duplication (NFC) (PR #79088)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud updated https://github.com/llvm/llvm-project/pull/79088

>From 8ba23b70c07f21be03102b2975046ca9a5afb90b Mon Sep 17 00:00:00 2001
From: Evgenii Kudriashov 
Date: Mon, 22 Jan 2024 18:00:19 -0800
Subject: [PATCH] [X86][GlobalISel] Remove G_OR/G_AND/G_XOR test duplication
 (NFC)

---
 .../test/CodeGen/X86/GlobalISel/and-scalar.ll | 60 ---
 llvm/test/CodeGen/X86/GlobalISel/or-scalar.ll | 60 ---
 .../test/CodeGen/X86/GlobalISel/xor-scalar.ll | 60 ---
 llvm/test/CodeGen/X86/isel-and.ll | 44 ++
 llvm/test/CodeGen/X86/isel-or.ll  | 45 ++
 llvm/test/CodeGen/X86/isel-xor.ll | 45 ++
 6 files changed, 134 insertions(+), 180 deletions(-)
 delete mode 100644 llvm/test/CodeGen/X86/GlobalISel/and-scalar.ll
 delete mode 100644 llvm/test/CodeGen/X86/GlobalISel/or-scalar.ll
 delete mode 100644 llvm/test/CodeGen/X86/GlobalISel/xor-scalar.ll

diff --git a/llvm/test/CodeGen/X86/GlobalISel/and-scalar.ll 
b/llvm/test/CodeGen/X86/GlobalISel/and-scalar.ll
deleted file mode 100644
index 88a7563612e231d..000
--- a/llvm/test/CodeGen/X86/GlobalISel/and-scalar.ll
+++ /dev/null
@@ -1,60 +0,0 @@
-; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=x86_64-linux-gnu -global-isel -verify-machineinstrs < %s 
-o - | FileCheck %s --check-prefix=ALL
-
-define i32 @test_and_i1(i32 %arg1, i32 %arg2) {
-; ALL-LABEL: test_and_i1:
-; ALL:   # %bb.0:
-; ALL-NEXT:cmpl %esi, %edi
-; ALL-NEXT:sete %al
-; ALL-NEXT:andb %al, %al
-; ALL-NEXT:movzbl %al, %eax
-; ALL-NEXT:andl $1, %eax
-; ALL-NEXT:retq
-  %c = icmp eq i32 %arg1, %arg2
-  %x = and i1 %c , %c
-  %ret = zext i1 %x to i32
-  ret i32 %ret
-}
-
-define i8 @test_and_i8(i8 %arg1, i8 %arg2) {
-; ALL-LABEL: test_and_i8:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:andb %dil, %al
-; ALL-NEXT:# kill: def $al killed $al killed $eax
-; ALL-NEXT:retq
-  %ret = and i8 %arg1, %arg2
-  ret i8 %ret
-}
-
-define i16 @test_and_i16(i16 %arg1, i16 %arg2) {
-; ALL-LABEL: test_and_i16:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:andw %di, %ax
-; ALL-NEXT:# kill: def $ax killed $ax killed $eax
-; ALL-NEXT:retq
-  %ret = and i16 %arg1, %arg2
-  ret i16 %ret
-}
-
-define i32 @test_and_i32(i32 %arg1, i32 %arg2) {
-; ALL-LABEL: test_and_i32:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:andl %edi, %eax
-; ALL-NEXT:retq
-  %ret = and i32 %arg1, %arg2
-  ret i32 %ret
-}
-
-define i64 @test_and_i64(i64 %arg1, i64 %arg2) {
-; ALL-LABEL: test_and_i64:
-; ALL:   # %bb.0:
-; ALL-NEXT:movq %rsi, %rax
-; ALL-NEXT:andq %rdi, %rax
-; ALL-NEXT:retq
-  %ret = and i64 %arg1, %arg2
-  ret i64 %ret
-}
-
diff --git a/llvm/test/CodeGen/X86/GlobalISel/or-scalar.ll 
b/llvm/test/CodeGen/X86/GlobalISel/or-scalar.ll
deleted file mode 100644
index 1edb72ca9b6cfcd..000
--- a/llvm/test/CodeGen/X86/GlobalISel/or-scalar.ll
+++ /dev/null
@@ -1,60 +0,0 @@
-; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=x86_64-linux-gnu -global-isel -verify-machineinstrs < %s 
-o - | FileCheck %s --check-prefix=ALL
-
-define i32 @test_or_i1(i32 %arg1, i32 %arg2) {
-; ALL-LABEL: test_or_i1:
-; ALL:   # %bb.0:
-; ALL-NEXT:cmpl %esi, %edi
-; ALL-NEXT:sete %al
-; ALL-NEXT:orb %al, %al
-; ALL-NEXT:movzbl %al, %eax
-; ALL-NEXT:andl $1, %eax
-; ALL-NEXT:retq
-  %c = icmp eq i32 %arg1, %arg2
-  %x = or i1 %c , %c
-  %ret = zext i1 %x to i32
-  ret i32 %ret
-}
-
-define i8 @test_or_i8(i8 %arg1, i8 %arg2) {
-; ALL-LABEL: test_or_i8:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:orb %dil, %al
-; ALL-NEXT:# kill: def $al killed $al killed $eax
-; ALL-NEXT:retq
-  %ret = or i8 %arg1, %arg2
-  ret i8 %ret
-}
-
-define i16 @test_or_i16(i16 %arg1, i16 %arg2) {
-; ALL-LABEL: test_or_i16:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:orw %di, %ax
-; ALL-NEXT:# kill: def $ax killed $ax killed $eax
-; ALL-NEXT:retq
-  %ret = or i16 %arg1, %arg2
-  ret i16 %ret
-}
-
-define i32 @test_or_i32(i32 %arg1, i32 %arg2) {
-; ALL-LABEL: test_or_i32:
-; ALL:   # %bb.0:
-; ALL-NEXT:movl %esi, %eax
-; ALL-NEXT:orl %edi, %eax
-; ALL-NEXT:retq
-  %ret = or i32 %arg1, %arg2
-  ret i32 %ret
-}
-
-define i64 @test_or_i64(i64 %arg1, i64 %arg2) {
-; ALL-LABEL: test_or_i64:
-; ALL:   # %bb.0:
-; ALL-NEXT:movq %rsi, %rax
-; ALL-NEXT:orq %rdi, %rax
-; ALL-NEXT:retq
-  %ret = or i64 %arg1, %arg2
-  ret i64 %ret
-}
-
diff --git a/llvm/test/CodeGen/X86/GlobalISel/xor-scalar.ll 
b/llvm/test/CodeGen/X86/GlobalISel/xor-scalar.ll
deleted file mode 100644
index 5a256d5875fcb6e..000
--- a/llvm/test/CodeGen/X86/GlobalISel/xor-scalar.ll
+++ /dev/null
@@ -1,60 +0,0 @@
-; NOTE: 

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

@@ -3963,6 +3963,60 @@ implicitly included in later levels.
 - ``-march=x86-64-v3``: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, 
LZCNT, MOVBE, XSAVE
 - ``-march=x86-64-v4``: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL
 
+`Intel AVX10 ISA `_ is
+a major new vector ISA incorporating the modern vectorization aspects of
+Intel AVX-512. This ISA will be supported on all future Intel processor.
+Users are supposed to use the new options ``-mavx10.N`` and ``-mavx10.N-512``
+on these processors and should not use traditional AVX512 options anymore.
+
+The ``N`` in ``-mavx10.N`` represents a continuous integer number starting
+from ``1``. ``-mavx10.N`` is an alias of ``-mavx10.N-256``, which means to
+enable all instructions within AVX10 version N at a maximum vector length of
+256 bits. ``-mavx10.N-512`` enables all instructions at a maximum vector
+length of 512 bits, which is a superset of instructions ``-mavx10.N`` enabled.
+
+Current binaries built with AVX512 features can run on Intel AVX10/512 capable
+processor without re-compile, but cannot run on AVX10/256 capable processor.
+Users need to re-compile their code with ``-mavx10.N``, and maybe update some
+code that calling to 512-bit X86 specific intrinsics and passing or returning
+512-bit vector types in function call, if they want to run on AVX10/256 capable
+processor. Binaries built with ``-mavx10.N`` can run on both AVX10/256 and
+AVX10/512 capable processor.
+
+Users can add a ``-mno-evex512`` in the command line with AVX512 options if
+they want to run the binary on both legacy AVX512 and new AVX10/256 capable
+processors. The option has the same constraints as ``-mavx10.N``, i.e.,
+cannot call to 512-bit X86 specific intrinsics and pass or return 512-bit 
vector
+types in function call.
+
+Users should avoid using AVX512 features in function target attributes when
+developing code for AVX10. If they have to do so, they need to add an explicit
+``evex512`` or ``no-evex512`` together with AVX512 features for 512-bit or
+non-512-bit functions respectively to avoid unexpected code generation. Both
+command line option and target attribute of EVEX512 feature can only be used
+with AVX512. They don't affect vector size of AVX10.
+
+User should not mix the use AVX10 and AVX512 options together at any time,
+because the option combinations are conflicting sometimes. For example, a
+combination of ``-mavx512f -mavx10.1-256`` doesn't show a clear intention to
+compiler, since instructions in AVX512F and AVX10.1/256 intersect but do not
+overlap. In this case, compiler will emit warning for it, but the behavior
+is determined. It will generate the same code as option ``-mavx10.1-512``.
+A similar case is ``-mavx512f -mavx10.2-256``, which equals to
+``-mavx10.1-512 -mavx10.2-256``, because ``avx10.2-256`` implies 
``avx10.1-256``
+and ``-mavx512f -mavx10.1-256`` equals to ``-mavx10.1-512``.
+
+There are some new macros introduced with AVX10 support. ``-mavx10.1-256`` will
+enable ``__AVX10_1__`` and ``__EVEX256__``, while ``-mavx10.1-512`` enables
+``__AVX10_1__``, ``__EVEX256__``, ``__EVEX512__``  and ``__AVX10_1_512__``.
+Besides, both ``-mavx10.1-256`` and ``-mavx10.1-512`` will enable all AVX512
+feature specific macros. A AVX512 feature will enable both ``__EVEX256__``,
+``__EVEX512__`` and its own macro. So ``__EVEX512__`` can be used to guard code
+that can run on both legacy AVX512 and AVX10/512 capable processors but cannot
+run on AVX10/256, while a AVX512 macro like ``__AVX512F__`` cannot tell the
+difference among the three options. Users need to check additional macros
+``__AVX10_1__`` and ``__EVEX512__`` if they want to make distinction.

e-kud wrote:

My idea was about scenario when you've migrated your sources to avx10 (e.g. 
using EVEX512 instead of AVX512F) but still have CI with different compilers 
that does not support it. I thought that it may be useful to provide some 
guidance. But I'm OK to leave it up to users. Whether they decide to specify 
versions or avx10 support availability.

https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

@@ -3963,6 +3963,60 @@ implicitly included in later levels.
 - ``-march=x86-64-v3``: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, 
LZCNT, MOVBE, XSAVE
 - ``-march=x86-64-v4``: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL
 
+`Intel AVX10 ISA `_ is
+a major new vector ISA incorporating the modern vectorization aspects of
+Intel AVX-512. This ISA will be supported on all future Intel processor.
+Users are supposed to use the new options ``-mavx10.N`` and ``-mavx10.N-512``
+on these processors and should not use traditional AVX512 options anymore.
+
+The ``N`` in ``-mavx10.N`` represents a continuous integer number starting
+from ``1``. ``-mavx10.N`` is an alias of ``-mavx10.N-256``, which means to
+enable all instructions within AVX10 version N at a maximum vector length of
+256 bits. ``-mavx10.N-512`` enables all instructions at a maximum vector
+length of 512 bits, which is a superset of instructions ``-mavx10.N`` enabled.
+
+Current binaries built with AVX512 features can run on Intel AVX10/512 capable
+processor without re-compile, but cannot run on AVX10/256 capable processor.
+Users need to re-compile their code with ``-mavx10.N``, and maybe update some
+code that calling to 512-bit X86 specific intrinsics and passing or returning
+512-bit vector types in function call, if they want to run on AVX10/256 capable
+processor. Binaries built with ``-mavx10.N`` can run on both AVX10/256 and
+AVX10/512 capable processor.
+
+Users can add a ``-mno-evex512`` in the command line with AVX512 options if
+they want to run the binary on both legacy AVX512 and new AVX10/256 capable
+processors. The option has the same constraints as ``-mavx10.N``, i.e.,
+cannot call to 512-bit X86 specific intrinsics and pass or return 512-bit 
vector
+types in function call.
+
+Users should avoid using AVX512 features in function target attributes when
+developing code for AVX10. If they have to do so, they need to add an explicit
+``evex512`` or ``no-evex512`` together with AVX512 features for 512-bit or
+non-512-bit functions respectively to avoid unexpected code generation. Both
+command line option and target attribute of EVEX512 feature can only be used
+with AVX512. They don't affect vector size of AVX10.
+
+User should not mix the use AVX10 and AVX512 options together at any time,
+because the option combinations are conflicting sometimes. For example, a
+combination of ``-mavx512f -mavx10.1-256`` doesn't show a clear intention to
+compiler, since instructions in AVX512F and AVX10.1/256 intersect but do not
+overlap. In this case, compiler will emit warning for it, but the behavior
+is determined. It will generate the same code as option ``-mavx10.1-512``.
+A similar case is ``-mavx512f -mavx10.2-256``, which equals to
+``-mavx10.1-512 -mavx10.2-256``, because ``avx10.2-256`` implies 
``avx10.1-256``
+and ``-mavx512f -mavx10.1-256`` equals to ``-mavx10.1-512``.
+
+There are some new macros introduced with AVX10 support. ``-mavx10.1-256`` will
+enable ``__AVX10_1__`` and ``__EVEX256__``, while ``-mavx10.1-512`` enables
+``__AVX10_1__``, ``__EVEX256__``, ``__EVEX512__``  and ``__AVX10_1_512__``.
+Besides, both ``-mavx10.1-256`` and ``-mavx10.1-512`` will enable all AVX512
+feature specific macros. A AVX512 feature will enable both ``__EVEX256__``,
+``__EVEX512__`` and its own macro. So ``__EVEX512__`` can be used to guard code
+that can run on both legacy AVX512 and AVX10/512 capable processors but cannot
+run on AVX10/256, while a AVX512 macro like ``__AVX512F__`` cannot tell the
+difference among the three options. Users need to check additional macros
+``__AVX10_1__`` and ``__EVEX512__`` if they want to make distinction.

e-kud wrote:

I don't know whether it matters to mention or not, but if a user want to 
compile code with old (before avx10 has been introduced) and new (after the 
introduction) compilers, then the user has to use something like this.

```if !defined(__AVX10_1__) && defined(__AVX512F__) || defined(__AVX512F__) && 
defined(__EVEX512__)```

https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AVX10][Doc] Add documentation about AVX10 options and their attentions (PR #77925)

[Evgenii Kudriashov via cfe-commits]

@@ -3963,6 +3963,60 @@ implicitly included in later levels.
 - ``-march=x86-64-v3``: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, 
LZCNT, MOVBE, XSAVE
 - ``-march=x86-64-v4``: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL
 
+`Intel AVX10 ISA `_ is
+a major new vector ISA incorporating the modern vectorization aspects of
+Intel AVX-512. This ISA will be supported on all future Intel processor.

e-kud wrote:

Processor**s**?

https://github.com/llvm/llvm-project/pull/77925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [X86][AVX10] Allow 64-bit mask register used without EVEX512 (PR #75571)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/75571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][AVX10] Fix a bug when using -march with no-evex512 attribute (PR #72126)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

Interesting. LGTM

https://github.com/llvm/llvm-project/pull/72126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][AVX10] Permit AVX512 options/features used together with AVX10 (PR #71318)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/71318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][AVX10] Permit AVX512 options/features used together with AVX10 (PR #71318)

[Evgenii Kudriashov via cfe-commits]

e-kud wrote:

I'm a little bit confused, What's the expected behavior of `+avx10.1-512 
-avx10.1-256` in codegen aspect. Should we generate only instructions in the 
difference of sets? Or do we consider `avx10.1-256` as a base of `avx10.1-512` 
and if it is disabled `avx10.1-512` can't be enabled?

https://github.com/llvm/llvm-project/pull/71318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][AVX10] Permit AVX512 options/features used together with AVX10 (PR #71318)

[Evgenii Kudriashov via cfe-commits]

@@ -131,35 +135,50 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (Feature.substr(0, 7) == "+avx10.") {
-  HasAVX10 = true;
-  HasAVX512F = true;
-  if (Feature.substr(Feature.size() - 3, 3) == "512") {
-HasEVEX512 = true;
-  } else if (Feature.substr(7, 2) == "1-") {
-HasEVEX512 = false;
+if (Feature.substr(1, 6) == "avx10.") {
+  if (Feature[0] == '+') {
+HasAVX10 = true;
+if (Feature.substr(Feature.size() - 3, 3) == "512")
+  HasAVX10_512 = true;
+LastAVX10 = Feature;
+  } else if (HasAVX10 && Feature == "-avx10.1-256") {
+HasAVX10 = false;
+HasAVX10_512 = false;
+  } else if (HasAVX10_512 && Feature == "-avx10.1-512") {
+HasAVX10_512 = false;
   }
+  // Postpone AVX10 features handling after AVX512 settled.
+  UpdatedAVX10FeaturesVec.push_back(Feature);
+  continue;
 } else if (!HasAVX512F && Feature.substr(0, 7) == "+avx512") {
   HasAVX512F = true;
+  LastAVX512 = Feature;
 } else if (HasAVX512F && Feature == "-avx512f") {
   HasAVX512F = false;
-} else if (HasAVX10 && Feature == "-avx10.1-256") {
-  HasAVX10 = false;
-  HasAVX512F = false;
-} else if (!HasEVEX512 && Feature == "+evex512") {
+} else if (HasEVEX512 != true && Feature == "+evex512") {
   HasEVEX512 = true;
-} else if (HasEVEX512 && Feature == "-avx10.1-512") {
-  HasEVEX512 = false;
-} else if (HasEVEX512 && Feature == "-evex512") {
+  continue;
+} else if (HasEVEX512 != false && Feature == "-evex512") {
   HasEVEX512 = false;
+  continue;
 }
 
 UpdatedFeaturesVec.push_back(Feature);
   }
-  if (HasAVX512F && HasEVEX512)
-UpdatedFeaturesVec.push_back("+evex512");
-  else if (HasAVX10)
-UpdatedFeaturesVec.push_back("-evex512");
+  llvm::append_range(UpdatedFeaturesVec, UpdatedAVX10FeaturesVec);

e-kud wrote:

Nope, there is a `continue` in handling `avx10*` features

https://github.com/llvm/llvm-project/pull/71318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

https://github.com/e-kud approved this pull request.

LGTM. Thanks!

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {
+HasEVEX512 = false;
+  }
+} else if (!HasAVX512F && Feature.substr(0, 7) == "+avx512") {
+  HasAVX512F = true;
+} else if (HasAVX512F && Feature == "-avx512f") {
+  HasAVX512F = false;
+} else if (HasAVX10 && Feature == "-avx10.1-256") {
+  HasAVX10 = false;
   HasAVX512F = false;
-if (HasEVEX512 && Feature == "-evex512")
+} else if (!HasEVEX512 && Feature == "+evex512") {
+  HasEVEX512 = true;
+} else if (HasEVEX512 && Feature == "-avx10.1-512") {

e-kud wrote:

`+avx10.1-512,-avx10.1-512` effectively means `+avx10.1-256`?

Generally, when I see such flag dangling, I'm used to thinking there is likely 
to be a bug. Do we have some reasoning that it is correct? Or maybe it's just 
my internal bias.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {

e-kud wrote:

I'm not sure whether the comment here is needed or not, but I've had the first 
question: why don't we reset `HasEVEX512` for `avx10.2-256`. And only after 
realization that `avx10.2-256` implies `avx10.1-256`, it makes sense.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [X86][RFC] Support AVX10 options (PR #67278)

[Evgenii Kudriashov via cfe-commits]

@@ -130,17 +131,35 @@ bool X86TargetInfo::initFeatureMap(
   continue;
 }
 
-if (!HasAVX512F && Feature.substr(0, 7) == "+avx512")
+if (Feature.substr(0, 7) == "+avx10.") {
+  HasAVX10 = true;
   HasAVX512F = true;
-if (HasAVX512F && Feature == "-avx512f")
+  if (Feature.substr(Feature.size() - 3, 3) == "512") {
+HasEVEX512 = true;
+  } else if (Feature.substr(7, 2) == "1-") {

e-kud wrote:

I'm not sure whether the comment here is needed or not, but I've had the first 
question: why don't we reset `HasEVEX512` for `avx10.2-256`. And only after 
realization that `avx10.2-256` implies `avx10.1-256`, it makes sense.

https://github.com/llvm/llvm-project/pull/67278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits