History log of /llvm-project/llvm/lib/CodeGen/MachineInstr.cpp (Results 151 – 175 of 809)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 06adfa17 30-Aug-2018 Carlos Alberto Enciso <carlos.alberto.enciso@gmail.com>

[DWARF] Missing location debug information with -O2.

Check that Machine CSE correctly handles during the transformation, the
debug location information for local variables.

Differential Revision: h

[DWARF] Missing location debug information with -O2.

Check that Machine CSE correctly handles during the transformation, the
debug location information for local variables.

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

llvm-svn: 341025

show more ...


Revision tags: llvmorg-7.0.0-rc2
# cc3f6302 20-Aug-2018 Krzysztof Parzyszek <kparzysz@codeaurora.org>

Consistently use MemoryLocation::UnknownSize to indicate unknown access size

1. Change the software pipeliner to use unknown size instead of dropping
memory operands. It used to do it before, but

Consistently use MemoryLocation::UnknownSize to indicate unknown access size

1. Change the software pipeliner to use unknown size instead of dropping
memory operands. It used to do it before, but MachineInstr::mayAlias
did not handle it correctly.
2. Recognize UnknownSize in MachineInstr::mayAlias.
3. Print and parse UnknownSize in MIR.

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

llvm-svn: 340208

show more ...


# 75ca6be1 16-Aug-2018 Chandler Carruth <chandlerc@gmail.com>

[x86/MIR] Implement support for pre- and post-instruction symbols, as
well as MIR parsing support for `MCSymbol` `MachineOperand`s.

The only real way to test pre- and post-instruction symbol support

[x86/MIR] Implement support for pre- and post-instruction symbols, as
well as MIR parsing support for `MCSymbol` `MachineOperand`s.

The only real way to test pre- and post-instruction symbol support is to
use them in operands, so I ended up implementing that within the patch
as well. I can split out the operand support if folks really want but it
doesn't really seem worth it.

The functional implementation of pre- and post-instruction symbols is
now *completely trivial*. Two tiny bits of code in the (misnamed)
AsmPrinter. It should be completely target independent as well. We emit
these exactly the same way as we emit basic block labels. Most of the
code here is to give full dumping, MIR printing, and MIR parsing support
so that we can write useful tests.

The MIR parsing of MC symbol operands still isn't 100%, as it forces the
symbols to be non-temporary and non-local symbols with names. However,
those names often can encode most (if not all) of the special semantics
desired, and unnamed symbols seem especially annoying to serialize and
de-serialize. While this isn't perfect or full support, it seems plenty
to write tests that exercise usage of these kinds of operands.

The MIR support for pre-and post-instruction symbols was quite
straightforward. I chose to print them out in an as-if-operand syntax
similar to debug locations as this seemed the cleanest way and let me
use nice introducer tokens rather than inventing more magic punctuation
like we use for memoperands.

However, supporting MIR-based parsing of these symbols caused me to
change the design of the symbol support to allow setting arbitrary
symbols. Without this, I don't see any reasonable way to test things
with MIR.

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

llvm-svn: 339962

show more ...


# c73c0307 16-Aug-2018 Chandler Carruth <chandlerc@gmail.com>

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


Revision tags: llvmorg-7.0.0-rc1
# 42f7bc96 21-Jun-2018 Mikael Holmen <mikael.holmen@ericsson.com>

[DebugInfo] Make sure all DBG_VALUEs' reguse operands have IsDebug property

Summary:
In some cases, these operands lacked the IsDebug property, which is meant to signal that
they should not affect c

[DebugInfo] Make sure all DBG_VALUEs' reguse operands have IsDebug property

Summary:
In some cases, these operands lacked the IsDebug property, which is meant to signal that
they should not affect codegen. This patch adds a check for this property in the
MachineVerifier and adds it where it was missing.

This includes refactorings to use MachineInstrBuilder construction functions instead of
manually setting up the intrinsic everywhere.

Patch by: JesperAntonsson

Reviewers: aprantl, rnk, echristo, javed.absar

Reviewed By: aprantl

Subscribers: qcolombet, sdardis, nemanjai, JDevlieghere, atanasyan, llvm-commits

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

llvm-svn: 335214

show more ...


# cafe9474 18-Jun-2018 Michael Berg <michael_c_berg@apple.com>

[NFC] make MIFlag accessor functions consistant with usage model

llvm-svn: 334970


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3
# b2d3f2e5 12-Jun-2018 Roman Tereshin <rtereshin@apple.com>

[MIR][MachineCSE] Implementing proper MachineInstr::getNumExplicitDefs()

Apparently, MachineInstr class definition as well as pretty much all of
the machine passes assume that the only kind of Machi

[MIR][MachineCSE] Implementing proper MachineInstr::getNumExplicitDefs()

Apparently, MachineInstr class definition as well as pretty much all of
the machine passes assume that the only kind of MachineInstr's operands
that is variadic for variadic opcodes is explicit non-definitions.

In particular, this assumption is made by MachineInstr::defs(), uses(),
and explicit_uses() methods, as well as by MachineCSE pass.

The assumption is incorrect judging from at least TableGen backend
implementation, that recognizes variable_ops in OutOperandList, and the
very existence of G_UNMERGE_VALUES generic opcode, or ARM load multiple
instructions, all of which have variadic defs.

In particular, MachineCSE pass breaks MIR with CSE'able G_UNMERGE_VALUES
instructions in it.

This commit implements MachineInstr::getNumExplicitDefs() similar to
pre-existing MachineInstr::getNumExplicitOperands(), fixes
MachineInstr::defs(), uses(), and explicit_uses(), and fixes MachineCSE
pass.

As the issue addressed seems to affect only machine passes that could be
ran mid-GlobalISel pipeline at the moment, the other passes aren't fixed
by this commit, like MachineLICM: that could be done on per-pass basis
when (if ever) they get adopted for GlobalISel.

Reviewed By: arsenm

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

llvm-svn: 334520

show more ...


Revision tags: llvmorg-6.0.1-rc2
# 801bf7eb 09-May-2018 Shiva Chen <shiva0217@gmail.com>

[DebugInfo] Examine all uses of isDebugValue() for debug instructions.

Because we create a new kind of debug instruction, DBG_LABEL, we need to
check all passes which use isDebugValue() to check Mac

[DebugInfo] Examine all uses of isDebugValue() for debug instructions.

Because we create a new kind of debug instruction, DBG_LABEL, we need to
check all passes which use isDebugValue() to check MachineInstr is debug
instruction or not. When expelling debug instructions, we should expel
both DBG_VALUE and DBG_LABEL. So, I create a new function,
isDebugInstr(), in MachineInstr to check whether the MachineInstr is
debug instruction or not.

This patch has no new test case. I have run regression test and there is
no difference in regression test.

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

Patch by Hsiangkai Wang.

llvm-svn: 331844

show more ...


# cd070cdc 09-May-2018 Shiva Chen <shiva0217@gmail.com>

[DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.

In order to convert LLVM IR to MachineInstr, we need a new TargetOpcode,
DBG_LABEL, to ‘lower’ intrinsic llvm.dbg.label. The patch
creat

[DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.

In order to convert LLVM IR to MachineInstr, we need a new TargetOpcode,
DBG_LABEL, to ‘lower’ intrinsic llvm.dbg.label. The patch
creates this new TargetOpcode and convert intrinsic llvm.dbg.label to
MachineInstr through SelectionDAG.

In SelectionDAG, debug information is stored in SDDbgInfo. We create a
new data member of SDDbgInfo for labels and use the new data member,
SDDbgLabel, to create DBG_LABEL MachineInstr.

The new DBG_LABEL MachineInstr uses label metadata from LLVM IR as its
parameter. So, the backend could get metadata information of labels from
DBG_LABEL MachineInstr.

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

Patch by Hsiangkai Wang.

llvm-svn: 331842

show more ...


# d29fc892 07-May-2018 Roman Tereshin <rtereshin@apple.com>

[MachineVerifier][GlobalISel] Checking that generic instrs have LLTs on all vregs

Every generic machine instruction must have generic virtual registers
only, that is, have a low-level type attached

[MachineVerifier][GlobalISel] Checking that generic instrs have LLTs on all vregs

Every generic machine instruction must have generic virtual registers
only, that is, have a low-level type attached to each operand.

Previously MachineVerifier would catch a type missing on an operand
only if the previous operand for the the same type index exists and
have a type attached to it and it will report it as a type mismatch.
This is incosistent behaviour and a misleading error message.

This commit makes sure MachineVerifier explicitly checks that the
types are there for every operand and if not provides a
straightforward error message.

Reviewers: qcolombet t.p.northover bogner ab

Reviewed By: qcolombet

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 331694

show more ...


# 7d1b25d0 03-May-2018 Michael Berg <michael_c_berg@apple.com>

MachineInst support mapping SDNode fast math flags for support in Back End code generation

Summary:
Machine Instruction flags for fast math support and MIR print support


Reviewers: spatel, arsenm

MachineInst support mapping SDNode fast math flags for support in Back End code generation

Summary:
Machine Instruction flags for fast math support and MIR print support


Reviewers: spatel, arsenm

Reviewed By: arsenm

Subscribers: wdng

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

llvm-svn: 331417

show more ...


# 432a3883 30-Apr-2018 Nico Weber <nicolasweber@gmx.de>

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()

found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))

and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.

No intended behavior change.

llvm-svn: 331184

show more ...


# 8ed0f741 24-Apr-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen] Print user-friendly debug locations as MI comments

If available, print the file, line and column of the DebugLoc attached
to the MachineInstr:

MOV16mr $rbp, 1, $noreg, -112, $noreg, kille

[CodeGen] Print user-friendly debug locations as MI comments

If available, print the file, line and column of the DebugLoc attached
to the MachineInstr:

MOV16mr $rbp, 1, $noreg, -112, $noreg, killed renamable $ax, debug-location !56 :: (store 2 into %ir.._value12); stepping.swift:10:17
renamable $edx = MOVZX32rm16 $rbp, 1, $noreg, -112, $noreg, debug-location !62 :: (dereferenceable load 2 from %ir.._value13); stepping.swift:10:17

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

llvm-svn: 330709

show more ...


Revision tags: llvmorg-6.0.1-rc1
# 71a4c0ca 10-Apr-2018 Krzysztof Parzyszek <kparzysz@codeaurora.org>

[CodeGen] Fix printing bundles in MIR output

Delay printing the newline until after the opening bracket was
printed, e.g.
BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 {
renamable $

[CodeGen] Fix printing bundles in MIR output

Delay printing the newline until after the opening bracket was
printed, e.g.
BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 {
renamable $r1 = S2_asr_i_r renamable $r1, 1
renamable $r21 = A2_tfrsi 0
}
instead of
BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1
{ renamable $r1 = S2_asr_i_r renamable $r1, 1
renamable $r21 = A2_tfrsi 0
}

llvm-svn: 329719

show more ...


Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1
# e85b06d6 14-Mar-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen] Use MIR syntax for MachineMemOperand printing

Get rid of the "; mem:" suffix and use the one we use in MIR: ":: (load 2)".

rdar://38163529

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

[CodeGen] Use MIR syntax for MachineMemOperand printing

Get rid of the "; mem:" suffix and use the one we use in MIR: ":: (load 2)".

rdar://38163529

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

llvm-svn: 327580

show more ...


# 084e7d87 14-Mar-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[AArch64] Keep track of MIFlags in the LoadStoreOptimizer

Merging:

* $x26, $x25 = frame-setup LDPXi $sp, 0
* $sp = frame-destroy ADDXri $sp, 64, 0

into an LDPXpost should preserve the flags from b

[AArch64] Keep track of MIFlags in the LoadStoreOptimizer

Merging:

* $x26, $x25 = frame-setup LDPXi $sp, 0
* $sp = frame-destroy ADDXri $sp, 64, 0

into an LDPXpost should preserve the flags from both instructions as
following:

* frame-setup frame-destroy LDPXpost

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

llvm-svn: 327533

show more ...


# 3abf0573 13-Mar-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[MIR] Allow frame-setup and frame-destroy on the same instruction

Nothing prevents us from having both frame-setup and frame-destroy on
the same instruction.

When merging:
* frame-setup OPCODE1
* f

[MIR] Allow frame-setup and frame-destroy on the same instruction

Nothing prevents us from having both frame-setup and frame-destroy on
the same instruction.

When merging:
* frame-setup OPCODE1
* frame-destroy OPCODE2
into
* frame-setup frame-destroy OPCODE3

we want to be able to print and parse both flags.

llvm-svn: 327442

show more ...


Revision tags: llvmorg-6.0.0
# 08389192 26-Feb-2018 Andrew V. Tischenko <andrew.v.tischenko@gmail.com>

The final step to close D41278 [MachineCombiner] Improve debug output (NFC).
Differential Revision: https://reviews.llvm.org/D41278

llvm-svn: 326074


# f8bf2ec0 23-Feb-2018 Geoff Berry <gberry@codeaurora.org>

[MachineOperand][Target] MachineOperand::isRenamable semantics changes

Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. T

[MachineOperand][Target] MachineOperand::isRenamable semantics changes

Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.

Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).

Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.

Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.

Clear the IsRenamable bit when changing an operand's register value.

Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.

Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.

Reviewers: qcolombet, MatzeB

Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits

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

llvm-svn: 325931

show more ...


Revision tags: llvmorg-6.0.0-rc3
# 68ced40a 19-Feb-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

Revert "[CodeGen] Move printing '\n' from MachineInstr::print to MachineBasicBlock::print"

This reverts commit r324681.

llvm-svn: 325505


# d65438d0 08-Feb-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen] Move printing '\n' from MachineInstr::print to MachineBasicBlock::print

MBB.print wasn't printing it, but the MIRPrinter is printing it. The
goal is to unify that as much as possible.

llv

[CodeGen] Move printing '\n' from MachineInstr::print to MachineBasicBlock::print

MBB.print wasn't printing it, but the MIRPrinter is printing it. The
goal is to unify that as much as possible.

llvm-svn: 324681

show more ...


Revision tags: llvmorg-6.0.0-rc2
# d37dc77b 29-Jan-2018 Geoff Berry <gberry@codeaurora.org>

[AMDGPU][X86][Mips] Make sure renamable bit not set for reserved regs

Summary:
Fix a few places that were modifying code after register
allocation to set the renamable bit correctly to avoid failing

[AMDGPU][X86][Mips] Make sure renamable bit not set for reserved regs

Summary:
Fix a few places that were modifying code after register
allocation to set the renamable bit correctly to avoid failing the
validation added in D42449.

llvm-svn: 323675

show more ...


# 548add99 19-Jan-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen] Unify printing format of debug-location in both MIR and -debug

Use "debug-location" instead of "; dbg:" in MI::print.

llvm-svn: 322936


# eb3f76fc 18-Jan-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen][NFC] Rename IsVerbose to IsStandalone in Machine*::print

Committed r322867 too soon.

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

llvm-svn: 322868


# 378b5f3d 18-Jan-2018 Francis Visoiu Mistrih <francisvm@yahoo.com>

[CodeGen] Print RegClasses on MI in verbose mode

r322086 removed the trailing information describing reg classes for each
register.

This patch adds printing reg classes next to every register when

[CodeGen] Print RegClasses on MI in verbose mode

r322086 removed the trailing information describing reg classes for each
register.

This patch adds printing reg classes next to every register when
individual operands/instructions/basic blocks are printed. In the case
of dumping MIR or printing a full function, by default don't print it.

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

llvm-svn: 322867

show more ...


12345678910>>...33