[X86] Use loaded/stored element size when parsing/printing gather/scatter pointer size in Intel syntax. (#122530)

This matches binutils.

[X86][AMX] Support AMX-TRANSPOSE (#113532)

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368

[MC] Replace some comparisons of MCRegister and literal 0. NFC

We can convert the MCRegister to bool instead. I think this should
allows us to remove MCRegister::operator==(int). All other compariso

[MC] Replace some comparisons of MCRegister and literal 0. NFC

We can convert the MCRegister to bool instead. I think this should
allows us to remove MCRegister::operator==(int). All other comparisons
in tree are unsigned.

show more ...

[X86] Use MCRegister in more places. NFC (#108682)

[MC] Make `MCParsedAsmOperand::getReg()` return `MCRegister` (#86444)

[NFC][X86] Reorder the registers to reduce unnecessary iterations (#70222)

* Introduce field `PositionOrder` for class `Register` and
`RegisterTuples`
* If register A's `PositionOrder` < register

[NFC][X86] Reorder the registers to reduce unnecessary iterations (#70222)

* Introduce field `PositionOrder` for class `Register` and
`RegisterTuples`
* If register A's `PositionOrder` < register B's `PositionOrder`, then A
is placed before B in the enum in X86GenRegisterInfo.inc
* The new order of registers in the enum for X86 will be
1. Registers before AVX512,
2. AVX512 registers (X/YMM16-31, ZMM0-31, K registers)
3. AMX registers (TMM)
4. APX registers (R16-R31)
* Add a new target hook `getNumSupportedRegs()` to return the number of
registers for the function (may overestimate).
* Replace `getNumRegs()` with `getNumSupportedRegs()` in LiveVariables
to eliminate iterations on unsupported registers

This patch can reduce 0.3% instruction count regression for sqlite3
during compile-stage (O3) by not iterating on APX registers
for #67702

show more ...

[X86][MC]Fix wrong action for encode movdir64b

Movdir64b is special for its mem operand, 67 prefex can not only modify its add size,
so it's mem base and index reg should be the same type as source

[X86][MC]Fix wrong action for encode movdir64b

Movdir64b is special for its mem operand, 67 prefex can not only modify its add size,
so it's mem base and index reg should be the same type as source reg, such as
movdir64b (%rdx), rcx, and could not be movdir64b (%edx), rcx.
Now llvm-mc can encode the asm 'movdir64b (%edx), rcx' but the result is the same as
'movdir64b (%edx), ecx', which offend users' intention, while gcc will object this
action and give a warning.
I add 3 new mem descriptions to let llvm-mc to report the same error.

Reviewed By: skan, craig.topper

Differential Revision: https://reviews.llvm.org/D145893

show more ...

[llvm-ml] Improve indirect call parsing

In MASM, if a QWORD symbol is passed to a jmp or call instruction in
64-bit mode or a DWORD or WORD symbol is passed in 32-bit mode, then
MSVC's assembler rec

[llvm-ml] Improve indirect call parsing

In MASM, if a QWORD symbol is passed to a jmp or call instruction in
64-bit mode or a DWORD or WORD symbol is passed in 32-bit mode, then
MSVC's assembler recognizes that as an indirect call. Additionally, if
the operand is qualified as a ptr, then that should also be an indirect
call.

Furthermore, in 64-bit mode, such operands are implicitly rip-relative
(in fact, MSVC's assembler ml64.exe does not allow explicitly specifying
rip as a base register.)

To keep this patch managable, this patch does not include:
* error messages for wrong operand types (e.g. passing a QWORD in 32-bit
mode)
* resolving indirect calls if the symbol is declared after it's first
use (llvm-ml currently only runs a single pass).
* imlementing the extern keyword (required to resolve
https://crbug.com/762167.)

This patch is likely missing a bunch of edge cases, so please do point
them out in the review.

Reviewed By: epastor, hans, MaskRay

Committed By: epastor (on behalf of ayzhao)

Differential Revision: https://reviews.llvm.org/D124413

show more ...

[llvm] Initialize and move UseUpRegs outside of `union` MemOp struct.

Asan complained about uninitialized bool

`invalid-bool-load`
llvm/lib/Target/X86/AsmParser/X86Operand.h:389:12: runtime error:

[llvm] Initialize and move UseUpRegs outside of `union` MemOp struct.

Asan complained about uninitialized bool

`invalid-bool-load`
llvm/lib/Target/X86/AsmParser/X86Operand.h:389:12: runtime error: load
of value 171, which is not a valid value for type 'bool'

Differential Revision: https://reviews.llvm.org/D122405

show more ...

[X86][NFC] Fix missing `override` in `isMemUseUpRegs`

Fix warning
```
warning: 'isMemUseUpRegs' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
```

[InlineAsm] Fix mangle problem when global variable used in inline asm
(Add modifier P for ARR[BaseReg+IndexReg+..])

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D120887

[Inline asm] Fix mangle problem when variable used in inline asm.
(Connect InlineAsm Memory Operand with its real value not just name)
Revert 2 history bugfix patch:

Revert "[X86][MS-InlineAsm] Make

[Inline asm] Fix mangle problem when variable used in inline asm.
(Connect InlineAsm Memory Operand with its real value not just name)
Revert 2 history bugfix patch:

Revert "[X86][MS-InlineAsm] Make the constraint *m to be simple place holder"
This patch revert https://reviews.llvm.org/D115225 which mainly
fix problems intrduced by https://reviews.llvm.org/D113096

This reverts commit d7c07f60b35f901f5bd9153b11807124a9bdde60.

Revert "Reland "[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables""
This patch revert https://reviews.llvm.org/D116090 which fix problem
intrduced by https://reviews.llvm.org/D115225

This reverts commit 24c68ea1eb4fc0d0e782424ddb02da9e8c53ddf5.

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D120886

show more ...

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llv

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llvm/MC/MCSubtargetInfo.h, llvm/MC/MCTargetOptions.h
llvm/MC/MCObjectStreamer.h no longer include llvm/MC/MCAssembler.h
llvm/MC/MCAssembler.h no longer includes llvm/MC/MCFixup.h, llvm/MC/MCFragment.h

Counting preprocessed lines required to rebuild llvm-project on my setup:
before: 1052436830
after: 1049293745

Which is significant and backs up the change in addition to the usual benefits of
decreasing coupling between headers and compilation units.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119244

show more ...

Reland "[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables"

This reverts commit a954558e878ed9e97e99036229e99af8c6b6c881.

Thanks Yuanfang's help. I think I found the root cau

Reland "[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables"

This reverts commit a954558e878ed9e97e99036229e99af8c6b6c881.

Thanks Yuanfang's help. I think I found the root cause of the buildbot
fail.

The failed test has both Memory and Immediate X86Operand. All data of
different operand kinds share the same memory space by a union
definition. So it has chance we get the wrong result if we don't check
the operand kind.

It's probably it happen to be the correct value in my local environment
so that I can't reproduce the fail.

Differential Revision: https://reviews.llvm.org/D116090

show more ...

Revert "[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables"

This reverts commit 682d01a1c1c52bd95d3d06267d6017395770256b.

Revert for buildbot fails.

[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables

D115225 tried to roll back the effects on symbols of MS inline asm
introduced by D113096. But the combination of the conditi

[X86][MS-InlineAsm] Use exact conditions to recognize MS global variables

D115225 tried to roll back the effects on symbols of MS inline asm
introduced by D113096. But the combination of the conditions cannot
match all the changes. As a result, there are still fails after the
patch.

This patch fixes the problem by checking the exact conditions for MS
global variables, i.e., variable (by FrontendSize != 0) + non rip/eip
(by DefaultBaseReg == 0), so that we can fully roll back for D113096.

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D116090

show more ...

[X86][MS-InlineAsm] Make the constraint *m to be simple place holder

D113096 solved the "undefined reference to xxx" issue by adding
constraint *m for the global var. But it has strong side effect d

[X86][MS-InlineAsm] Make the constraint *m to be simple place holder

D113096 solved the "undefined reference to xxx" issue by adding
constraint *m for the global var. But it has strong side effect due to
the symbol in the assembly being replaced with constraint variable.
This leads to some lowering fails. https://godbolt.org/z/h3nWoerPe

This patch fix the problem by use the constraint *m as place holder
rather than real constraint. It has negligible effect for the existing
code generation.

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D115225

show more ...

[X86] Remove CallOperand in X86Operand (NFC)

This field seems to be unused for at least one year.

X86Operand.h - fix uninitialized variable warnings in constructor. NFCI.

[X86] Allow lsl/lar to be parsed with a GR16, GR32, or GR64 as source register.

This matches GNU assembler behavior. Operand size is determined
only from the destination register.

[X86-64] Support Intel AMX instructions

Summary:
INTEL ADVANCED MATRIX EXTENSIONS (AMX).
AMX is a new programming paradigm, it has a set of 2-dimensional registers
(TILES) representing sub-arrays fr

[X86-64] Support Intel AMX instructions

Summary:
INTEL ADVANCED MATRIX EXTENSIONS (AMX).
AMX is a new programming paradigm, it has a set of 2-dimensional registers
(TILES) representing sub-arrays from a larger 2-dimensional memory image and
operate on TILES.

Spec can be found in Chapter 3 here https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewers: LuoYuanke, annita.zhang, pengfei, RKSimon, xiangzhangllvm

Reviewed By: xiangzhangllvm

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D82705

show more ...

[ms] [llvm-ml] Use default RIP-relative addressing for x64 MASM.

Summary:
When parsing 64-bit MASM, treat memory operands with unspecified base register as RIP-based.

Documented in several places,

[ms] [llvm-ml] Use default RIP-relative addressing for x64 MASM.

Summary:
When parsing 64-bit MASM, treat memory operands with unspecified base register as RIP-based.

Documented in several places, including https://software.intel.com/en-us/articles/introduction-to-x64-assembly: "Unfortunately, MASM does not allow this form of opcode, but other assemblers like FASM and YASM do. Instead, MASM embeds RIP-relative addressing implicitly."

Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D73227

show more ...

[X86][llvm-mc] Make the suffix matcher more accurate.

Summary:
Some instruction like VPMULDQ is NOT the variant of VPMULD but a new
one.
So we should make sure the suffix matcher only works for memo

[X86][llvm-mc] Make the suffix matcher more accurate.

Summary:
Some instruction like VPMULDQ is NOT the variant of VPMULD but a new
one.
So we should make sure the suffix matcher only works for memory variant
that has the same size with the suffix.
Currently we only check for SSE/AVX* instructions, because many legacy
instructions didn't declare the alias instructions of their variants.

Differential Revision: https://reviews.llvm.org/D80608

show more ...

X86Operand.h - remove unnecessary includes. NFC.

[ms] [X86] Use "P" modifier on all branch-target operands in inline X86 assembly.

Summary:
Extend D71677 to apply to all branch-target operands, rather than special-casing call instructions.

Also a

[ms] [X86] Use "P" modifier on all branch-target operands in inline X86 assembly.

Summary:
Extend D71677 to apply to all branch-target operands, rather than special-casing call instructions.

Also add a regression test for llvm.org/PR44272, since this finishes fixing it.

Reviewers: thakis, rnk

Reviewed By: thakis

Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D72417

show more ...