[Hexagon] Do not optimize address of another function's block (#101209)

When the constant extender optimization pass encounters an instruction
that uses an extended address pointing to another func

[Hexagon] Do not optimize address of another function's block (#101209)

When the constant extender optimization pass encounters an instruction
that uses an extended address pointing to another function's block,
avoid adding the instruction to the extender list for the current
machine function.

Fixes https://github.com/llvm/llvm-project/issues/99714

show more ...

[CodeGen][NewPM] Split `MachineDominatorTree` into a concrete analysis result (#94571)

Prepare for new pass manager version of `MachineDominatorTreeAnalysis`.
We may need a machine dominator tree v

[CodeGen][NewPM] Split `MachineDominatorTree` into a concrete analysis result (#94571)

Prepare for new pass manager version of `MachineDominatorTreeAnalysis`.
We may need a machine dominator tree version of `DomTreeUpdater` to
handle `SplitCriticalEdge` in some CodeGen passes.

show more ...

Add llvm::min/max_element and use it in llvm/ and mlir/ directories. (#84678)

For some reason this was missing from STLExtras.

[Target] Use llvm::count{l,r}_{zero,one} (NFC)

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the err

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the error has been removed,
cl::ZeroOrMore is unneeded.

Also remove cl::init(false) while touching the lines.

show more ...

Cleanup includes: DebugInfo & CodeGen

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

[Hexagon] Use llvm::Register instead of unsigned in HexagonConstExtenders.cpp. NFC.

Reviewed By: kparzysz

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

[NFC][llvm][Hexagon] Inclusive Terms remove uses of sanity in Hexagon taget

Most changes are rewording comments but there are some assertions that I rephrased.

Reviewed By: kparzysz

Differential R

[NFC][llvm][Hexagon] Inclusive Terms remove uses of sanity in Hexagon taget

Most changes are rewording comments but there are some assertions that I rephrased.

Reviewed By: kparzysz

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

show more ...

[NFC] Use [MC]Register for Hexagon target

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

[Hexagon] Add a target feature to disable compound instructions

This affects the following instructions:
Tag: M4_mpyrr_addr Syntax: Ry32 = add(Ru32,mpyi(Ry32,Rs32))
Tag: M4_mpyri_addr_u2 Syntax

[Hexagon] Add a target feature to disable compound instructions

This affects the following instructions:
Tag: M4_mpyrr_addr Syntax: Ry32 = add(Ru32,mpyi(Ry32,Rs32))
Tag: M4_mpyri_addr_u2 Syntax: Rd32 = add(Ru32,mpyi(#u6:2,Rs32))
Tag: M4_mpyri_addr Syntax: Rd32 = add(Ru32,mpyi(Rs32,#u6))
Tag: M4_mpyri_addi Syntax: Rd32 = add(#u6,mpyi(Rs32,#U6))
Tag: M4_mpyrr_addi Syntax: Rd32 = add(#u6,mpyi(Rs32,Rt32))
Tag: S4_addaddi Syntax: Rd32 = add(Rs32,add(Ru32,#s6))
Tag: S4_subaddi Syntax: Rd32 = add(Rs32,sub(#s6,Ru32))
Tag: S4_or_andix Syntax: Rx32 = or(Ru32,and(Rx32,#s10))
Tag: S4_andi_asl_ri Syntax: Rx32 = and(#u8,asl(Rx32,#U5))
Tag: S4_ori_asl_ri Syntax: Rx32 = or(#u8,asl(Rx32,#U5))
Tag: S4_addi_asl_ri Syntax: Rx32 = add(#u8,asl(Rx32,#U5))
Tag: S4_subi_asl_ri Syntax: Rx32 = sub(#u8,asl(Rx32,#U5))
Tag: S4_andi_lsr_ri Syntax: Rx32 = and(#u8,lsr(Rx32,#U5))
Tag: S4_ori_lsr_ri Syntax: Rx32 = or(#u8,lsr(Rx32,#U5))
Tag: S4_addi_lsr_ri Syntax: Rx32 = add(#u8,lsr(Rx32,#U5))
Tag: S4_subi_lsr_ri Syntax: Rx32 = sub(#u8,lsr(Rx32,#U5))

show more ...

[Hexagon] Fixes -Wrange-loop-analysis warnings

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

Make more use of MachineInstr::mayLoadOrStore.

Sink all InitializePasses.h includes

This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of reco

Sink all InitializePasses.h includes

This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.

I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h

Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.

Reviewers: bkramer, asbirlea, bollu, jdoerfert

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

show more ...

Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM

Summary:
This clang-tidy check is looking for unsigned integer variables whose initializer
starts with an implicit cast from llvm::Re

Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM

Summary:
This clang-tidy check is looking for unsigned integer variables whose initializer
starts with an implicit cast from llvm::Register and changes the type of the
variable to llvm::Register (dropping the llvm:: where possible).

Partial reverts in:
X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister
X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister
X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister
HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned&
MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register
PPCFastISel.cpp - No Register::operator-=()
PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned&
MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor

Manual fixups in:
ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned&
HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register
HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register.
PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned&

Depends on D65919

Reviewers: arsenm, bogner, craig.topper, RKSimon

Reviewed By: arsenm

Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits

Tags: #llvm

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

llvm-svn: 369041

show more ...

Finish moving TargetRegisterInfo::isVirtualRegister() and friends to llvm::Register as started by r367614. NFC

llvm-svn: 367633

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Fix clang -Wimplicit-fallthrough warnings across llvm, NFC

This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the

Fix clang -Wimplicit-fallthrough warnings across llvm, NFC

This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.

We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.

I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.

Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu

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

llvm-svn: 345882

show more ...

[Hexagon] Fix MO_JumpTable const extender conversion

Previously this case fell through to unreachable, so it is clearly not
covered by any test case in LLVM. It may be dynamically unreachable, in
fa

[Hexagon] Fix MO_JumpTable const extender conversion

Previously this case fell through to unreachable, so it is clearly not
covered by any test case in LLVM. It may be dynamically unreachable, in
fact. However, if it were to run, this is what it would logically do.
The assert suggests that the intended behavior was not to allow folding
offsets from jump table indices, which makes sense.

llvm-svn: 345868

show more ...

[Hexagon] Eliminate potential sources of non-determinism in HCE

Also, avoid comparing GUIDs when ordering global addresses, because
source file location can cause different GUID to be calculated. As

[Hexagon] Eliminate potential sources of non-determinism in HCE

Also, avoid comparing GUIDs when ordering global addresses, because
source file location can cause different GUID to be calculated. As a
result, a pair of symbols can compare "less" in one directory, but
"greater" in another.

llvm-svn: 344271

show more ...

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscr

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits

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

llvm-svn: 343163

show more ...

[Hexagon] Avoid functions with exception handling in HexagonConstExtenders

The constant-extender optimization does a form of code motion, which is
complicated in the presence of exception handling.

[Hexagon] Avoid functions with exception handling in HexagonConstExtenders

The constant-extender optimization does a form of code motion, which is
complicated in the presence of exception handling.

llvm-svn: 342751

show more ...

[Hexagon] Split large offsets into properly aligned addends

llvm-svn: 341851

[Hexagon] Ignore unnamed globals in HexagonConstExtenders

This replaces r337723. The global list in the module can be huge with LTO,
plus the module can change between different invocations of the p

[Hexagon] Ignore unnamed globals in HexagonConstExtenders

This replaces r337723. The global list in the module can be huge with LTO,
plus the module can change between different invocations of the pass, so
there is no easy way to deterministically cache the ordering (especially
in the presence of multiple threads).

llvm-svn: 341478

show more ...

[MI] Change the array of `MachineMemOperand` pointers to be
a generically extensible collection of extra info attached to
a `MachineInstr`.

The primary change here is cleaning up the APIs used for s

[MI] Change the array of `MachineMemOperand` pointers to be
a generically extensible collection of extra info attached to
a `MachineInstr`.

The primary change here is cleaning up the APIs used for setting and
manipulating the `MachineMemOperand` pointer arrays so chat we can
change how they are allocated.

Then we introduce an extra info object that using the trailing object
pattern to attach some number of MMOs but also other extra info. The
design of this is specifically so that this extra info has a fixed
necessary cost (the header tracking what extra info is included) and
everything else can be tail allocated. This pattern works especially
well with a `BumpPtrAllocator` which we use here.

I've also added the basic scaffolding for putting interesting pointers
into this, namely pre- and post-instruction symbols. These aren't used
anywhere yet, they're just there to ensure I've actually gotten the data
structure types correct. I'll flesh out support for these in
a subsequent patch (MIR dumping, parsing, the works).

Finally, I've included an optimization where we store any single pointer
inline in the `MachineInstr` to avoid the allocation overhead. This is
expected to be the overwhelmingly most common case and so should avoid
any memory usage growth due to slightly less clever / dense allocation
when dealing with >1 MMO. This did require several ergonomic
improvements to the `PointerSumType` to reasonably support the various
usage models.

This also has a side effect of freeing up 8 bits within the
`MachineInstr` which could be repurposed for something else.

The suggested direction here came largely from Hal Finkel. I hope it was
worth it. ;] It does hopefully clear a path for subsequent extensions
w/o nearly as much leg work. Lots of thanks to Reid and Justin for
careful reviews and ideas about how to do all of this.

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

llvm-svn: 339940

show more ...

[Hexagon] Handle unnamed globals in HexagonConstExpr

Instead of comparing names, compare positions in the parent module.

llvm-svn: 337723