Revert "Rebase: [Facebook] [MC] Introduce NeverAlign fragment type"

This reverts commit 6d0528636ae54fba75938a79ae7a98dfcc949f72.

Rebase: [Facebook] [MC] Introduce NeverAlign fragment type

Summary:
Introduce NeverAlign fragment type.

The intended usage of this fragment is to insert it before a pair of
macro-op fusion eligible

Rebase: [Facebook] [MC] Introduce NeverAlign fragment type

Summary:
Introduce NeverAlign fragment type.

The intended usage of this fragment is to insert it before a pair of
macro-op fusion eligible instructions. NeverAlign fragment ensures that
the next fragment (first instruction in the pair) does not end at a
given alignment boundary by emitting a minimal size nop if necessary.

In effect, it ensures that a pair of macro-fusible instructions is not
split by a given alignment boundary, which is a precondition for
macro-op fusion in modern Intel Cores (64B = cache line size, see Intel
Architecture Optimization Reference Manual, 2.3.2.1 Legacy Decode
Pipeline: Macro-Fusion).

This patch introduces functionality used by BOLT when emitting code with
MacroFusion alignment already in place.

The use case is different from BoundaryAlign and instruction bundling:
- BoundaryAlign can be extended to perform the desired alignment for the
first instruction in the macro-op fusion pair (D101817). However, this
approach has higher overhead due to reliance on relaxation as
BoundaryAlign requires in the general case - see
https://reviews.llvm.org/D97982#2710638.
- Instruction bundling: the intent of NeverAlign fragment is to prevent
the first instruction in a pair ending at a given alignment boundary, by
inserting at most one minimum size nop. It's OK if either instruction
crosses the cache line. Padding both instructions using bundles to not
cross the alignment boundary would result in excessive padding. There's
no straightforward way to request instruction bundling to avoid a given
end alignment for the first instruction in the bundle.

LLVM: https://reviews.llvm.org/D97982

Manual rebase conflict history:
https://phabricator.intern.facebook.com/D30142613

Test Plan: sandcastle

Reviewers: #llvm-bolt

Subscribers: phabricatorlinter

Differential Revision: https://phabricator.intern.facebook.com/D31361547

show more ...

[X86][NFC] Use mnemonic tables in validateInstruction 4/4

Group switch cases by opcode:
- VGATHERDPD
- VGATHERDPS
- VGATHERQPD
- VGATHERQPS
- VPGATHERDD
- VPGATHERDQ
- VPGATHERQD
- VPGATHERQQ

Disti

[X86][NFC] Use mnemonic tables in validateInstruction 4/4

Group switch cases by opcode:
- VGATHERDPD
- VGATHERDPS
- VGATHERQPD
- VGATHERQPS
- VPGATHERDD
- VPGATHERDQ
- VPGATHERQD
- VPGATHERQQ

Distinguish masked vs non-masked forms by EVEX encoding.

Reviewed By: skan, craig.topper

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

show more ...

[X86][NFC] Use mnemonic tables in validateInstruction 3/4

Group switch cases by opcode:
- V4FMADDPS
- V4FMADDSS
- V4FNMADDPS
- V4FNMADDSS
- VP4DPWSSDS
- VP4DPWSSD

Reviewed By: craig.topper

Differe

[X86][NFC] Use mnemonic tables in validateInstruction 3/4

Group switch cases by opcode:
- V4FMADDPS
- V4FMADDSS
- V4FNMADDPS
- V4FNMADDSS
- VP4DPWSSDS
- VP4DPWSSD

Reviewed By: craig.topper

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

show more ...

[X86][NFC] Use mnemonic tables in validateInstruction 2/4

Group switch cases by opcode:
- VFCMULCPH
- VFCMULCSH
- VFMULCPH
- VFMULCSH

Reviewed By: craig.topper

Differential Revision: https://revie

[X86][NFC] Use mnemonic tables in validateInstruction 2/4

Group switch cases by opcode:
- VFCMULCPH
- VFCMULCSH
- VFMULCPH
- VFMULCSH

Reviewed By: craig.topper

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

show more ...

[X86][NFC] Use mnemonic tables in validateInstruction 1/4

Group switch cases by opcode:
- VFCMADDCPH
- VFCMADDCSH
- VFMADDCPH
- VFMADDCSH

Reviewed By: craig.topper

Differential Revision: https://r

[X86][NFC] Use mnemonic tables in validateInstruction 1/4

Group switch cases by opcode:
- VFCMADDCPH
- VFCMADDCSH
- VFMADDCPH
- VFMADDCSH

Reviewed By: craig.topper

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

show more ...

[X86] Use default member initialization (NFC)

Identified with modernize-use-default-member-init.

[MC] Change EndOfStatement "unexpected tokens in .xxx directive " to "expected newline"

[MC] Lower case the first letter of EmitCOFF* EmitWin* EmitCV*. NFC

[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 ...

[Inline asm] Fix mangle problem when variable used in inline asm.
(Correct 'Mem symbol + IntelExpr' output in PIC model)

Reviewed By: skan

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

[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 ...

[X86] Rename more target feature related things consistency. NFC

-Rename Mode*Bit to Is*Bit to match X86Subtarget.
-Rename FeatureLAHFSAHF to FeatureLAFHSAFH64 to match X86Subtarget.
-Use consistent

[X86] Rename more target feature related things consistency. NFC

-Rename Mode*Bit to Is*Bit to match X86Subtarget.
-Rename FeatureLAHFSAHF to FeatureLAFHSAFH64 to match X86Subtarget.
-Use consistent capitalization

Reviewed By: skan

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

show more ...

[MC] Fix letter case of some MCSection member functions

[NFC] Fix typos

Reviewed By: yota9, Amir

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

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

[llvm] Use true/false instead of 1/0 (NFC)

Identified with modernize-use-bool-literals.

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 ...

[llvm] Use llvm::count (NFC)

[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 ...

[NFC][llvm] Inclusive language: reword and remove uses of sanity in llvm/lib/Target

Reworded removed code comments that contain `sanity check` and `sanity
test`.