History log of /llvm-project/llvm/lib/CodeGen/MachineInstr.cpp (Results 201 – 225 of 809)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# ec7cba53 10-Oct-2017 Justin Bogner <mail@justinbogner.com>

CodeGen: Add MachineInstr::getMF(). NFC

Similarly to how Instruction has getFunction, this adds a less verbose
way to write MI->getParent()->getParent(). I'll follow up shortly with
a change that ch

CodeGen: Add MachineInstr::getMF(). NFC

Similarly to how Instruction has getFunction, this adds a less verbose
way to write MI->getParent()->getParent(). I'll follow up shortly with
a change that changes a bunch of the uses.

llvm-svn: 315388

show more ...


# 9e6c309e 15-Sep-2017 Reid Kleckner <rnk@google.com>

[DebugInfo] Add missing DW_OP_deref when an NRVO pointer is spilled

Summary:
Fixes PR34513.

Indirect DBG_VALUEs typically come from dbg.declares of non-trivially
copyable C++ objects that must be p

[DebugInfo] Add missing DW_OP_deref when an NRVO pointer is spilled

Summary:
Fixes PR34513.

Indirect DBG_VALUEs typically come from dbg.declares of non-trivially
copyable C++ objects that must be passed by address. We were already
handling the case where the virtual register gets allocated to a
physical register and is later spilled. That's what usually happens for
normal parameters that aren't NRVO variables: they usually appear in
physical register parameters, and are spilled later in the function,
which would correctly add deref.

NRVO variables are different because the dbg.declare can come much later
after earlier instructions cause the incoming virtual register to be
spilled.

Also, clean up this code. We only need to look at the first operand of a
DBG_VALUE, which eliminates the operand loop.

Reviewers: aprantl, dblaikie, probinson

Subscribers: MatzeB, qcolombet, llvm-commits, hiraditya

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

llvm-svn: 313399

show more ...


# 312ccf76 14-Sep-2017 Jan Sjodin <jan_sjodin@yahoo.com>

Add AddresSpace to PseudoSourceValue.

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

llvm-svn: 313297


Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5
# 42adadfc 30-Aug-2017 Balaram Makam <bmakam@codeaurora.org>

Re-land MachineInstr: Reason locally about some memory objects before going to AA.

Summary:
Reverts r311008 to reinstate r310825 with a fix.

Refine alias checking for pseudo vs value to be conserva

Re-land MachineInstr: Reason locally about some memory objects before going to AA.

Summary:
Reverts r311008 to reinstate r310825 with a fix.

Refine alias checking for pseudo vs value to be conservative.
This fixes the original failure in builtbot unittest SingleSource/UnitTests/2003-07-09-SignedArgs.

Reviewers: hfinkel, nemanjai, efriedma

Reviewed By: efriedma

Subscribers: bjope, mcrosier, nhaehnle, javed.absar, llvm-commits

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

llvm-svn: 312126

show more ...


Revision tags: llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3
# c5698bef 16-Aug-2017 Balaram Makam <bmakam@codeaurora.org>

Revert "MachineInstr: Reason locally about some memory objects before going to AA."

r310825 caused the clang-ppc64le-linux-lnt bot to go red
(http://lab.llvm.org:8011/builders/clang-ppc64le-linux-ln

Revert "MachineInstr: Reason locally about some memory objects before going to AA."

r310825 caused the clang-ppc64le-linux-lnt bot to go red
(http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/5712)
because of a test-suite failure of
SingleSource/UnitTests/2003-07-09-SignedArgs

This reverts commit 0028f6a87224fb595a1c19c544cde9b003035996.

llvm-svn: 311008

show more ...


# d9f53414 14-Aug-2017 Balaram Makam <bmakam@codeaurora.org>

MachineInstr: Reason locally about some memory objects before going to AA.

This addresses a FIXME in MachineInstr::mayAlias.

llvm-svn: 310825


Revision tags: llvmorg-5.0.0-rc2
# 8de4bbda 04-Aug-2017 Marcello Maggioni <hayarms@gmail.com>

[MachineOperand] Add ChangeToTargetIndex method. NFC

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

llvm-svn: 310083


# 51296593 03-Aug-2017 Simon Dardis <simon.dardis@imgtec.com>

[SelectionDAG] Resolve PR33978.

rL306209 taught SelectionDAG how to add the dereferenceable flag when
expanding memcpy and memmove. The fix however contained a nit where
the offset + size was constr

[SelectionDAG] Resolve PR33978.

rL306209 taught SelectionDAG how to add the dereferenceable flag when
expanding memcpy and memmove. The fix however contained a nit where
the offset + size was constructed as an APInt of PointerSize rather
than PointerSizeInBits.

This lead to isDereferenceableAndAlignedPointer() get truncated values or
values which would be sign extended within that function leading to
incorrect results.

Thanks to Alex Crichton for reporting the issue!

This resolves PR33978.

Reviewers: inouehrs

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

llvm-svn: 309930

show more ...


# 8b9bb534 28-Jul-2017 Adrian Prantl <aprantl@apple.com>

Remove the unused offset from DBG_VALUE (NFC)

Followup to r309426.
rdar://problem/33580047

llvm-svn: 309450


Revision tags: llvmorg-5.0.0-rc1
# db78273b 20-Jul-2017 Matt Arsenault <Matthew.Arsenault@amd.com>

Add an ID field to StackObjects

On AMDGPU SGPR spills are really spilled to another register.
The spiller creates the spills to new frame index objects,
which is used as a placeholder.

This will ev

Add an ID field to StackObjects

On AMDGPU SGPR spills are really spilled to another register.
The spiller creates the spills to new frame index objects,
which is used as a placeholder.

This will eventually be replaced with a reference to a position
in a VGPR to write to and the frame index deleted. It is
most likely not a real stack location that can be shared
with another stack object.

This is a problem when StackSlotColoring decides it should
combine a frame index used for a normal VGPR spill with
a real stack location and a frame index used for an SGPR.

Add an ID field so that StackSlotColoring has a way
of knowing the different frame index types are
incompatible.

llvm-svn: 308673

show more ...


# d62fe830 20-Jul-2017 Matt Arsenault <Matthew.Arsenault@amd.com>

Replace -print-whole-regmask with a threshold.

The previous flag/default of printing everything is
not helpful when there are thousands of registers
in the mask.

llvm-svn: 308572


# 6748abe2 13-Jul-2017 Geoff Berry <gberry@codeaurora.org>

[MIR] Add support for printing and parsing target MMO flags

Summary: Add target hooks for printing and parsing target MMO flags.
Targets may override getSerializableMachineMemOperandTargetFlags() to

[MIR] Add support for printing and parsing target MMO flags

Summary: Add target hooks for printing and parsing target MMO flags.
Targets may override getSerializableMachineMemOperandTargetFlags() to
return a mapping from string to flag value for target MMO values that
should be serialized/parsed in MIR output.

Add implementation of this hook for AArch64 SuppressPair MMO flag.

Reviewers: bogner, hfinkel, qcolombet, MatzeB

Subscribers: mcrosier, javed.absar, llvm-commits

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

llvm-svn: 307877

show more ...


# bb80d3e1 11-Jul-2017 Konstantin Zhuravlyov <kzhuravl_dev@outlook.com>

Enhance synchscope representation

OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, whic

Enhance synchscope representation

OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, which can result in improved performance.

This change extends existing notion of synchronization scopes in LLVM to
support arbitrary scopes expressed as target-specific strings, in addition to
the already defined scopes (single thread, system).

The LLVM IR and MIR syntax for expressing synchronization scopes has changed
to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this
replaces *singlethread* keyword), or a target-specific name. As before, if
the scope is not specified, it defaults to CrossThread/System scope.

Implementation details:
- Mapping from synchronization scope name/string to synchronization scope id
is stored in LLVM context;
- CrossThread/System and SingleThread scopes are pre-defined to efficiently
check for known scopes without comparing strings;
- Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in
the bitcode.

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

llvm-svn: 307722

show more ...


# 55e2f596 05-Jul-2017 Igor Breger <igor.breger@intel.com>

[GlobalIsel] allow x86_fp80 values to be dumped.

Summary:
Otherwise the fallback path fails with an assertion on x86_64 targets,
when "x86_fp80" is encountered.

Reviewers: t.p.northover, zvi, guybl

[GlobalIsel] allow x86_fp80 values to be dumped.

Summary:
Otherwise the fallback path fails with an assertion on x86_64 targets,
when "x86_fp80" is encountered.

Reviewers: t.p.northover, zvi, guyblank

Reviewed By: zvi

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 307140

show more ...


# 559aa753 29-Jun-2017 Daniel Jasper <djasper@google.com>

Revert "r306529 - [X86] Correct dwarf unwind information in function epilogue"

I am 99% sure that this breaks the PPC ASAN build bot:
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds

Revert "r306529 - [X86] Correct dwarf unwind information in function epilogue"

I am 99% sure that this breaks the PPC ASAN build bot:
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3112/steps/64-bit%20check-asan/logs/stdio

If it doesn't go back to green, we can recommit (and fix the original
commit message at the same time :) ).

llvm-svn: 306676

show more ...


# 7b3a38ec 28-Jun-2017 Petar Jovanovic <petar.jovanovic@imgtec.com>

[X86] Correct dwarf unwind information in function epilogue

CFI instructions that set appropriate cfa offset and cfa register are now
inserted in emitEpilogue() in X86FrameLowering.

Majority of the

[X86] Correct dwarf unwind information in function epilogue

CFI instructions that set appropriate cfa offset and cfa register are now
inserted in emitEpilogue() in X86FrameLowering.

Majority of the changes in this patch:

1. Ensure that CFI instructions do not affect code generation.
2. Enable maintaining correct information about cfa offset and cfa register
in a function when basic blocks are reordered, merged, split, duplicated.

These changes are target independent and described below.

Changed CFI instructions so that they:

1. are duplicable
2. are not counted as instructions when tail duplicating or tail merging
3. can be compared as equal

Add information to each MachineBasicBlock about cfa offset and cfa register
that are valid at its entry and exit (incoming and outgoing CFI info). Add
support for updating this information when basic blocks are merged, split,
duplicated, created. Add a verification pass (CFIInfoVerifier) that checks
that outgoing cfa offset and register of predecessor blocks match incoming
values of their successors.

Incoming and outgoing CFI information is used by a late pass
(CFIInstrInserter) that corrects CFA calculation rule for a basic block if
needed. That means that additional CFI instructions get inserted at basic
block beginning to correct the rule for calculating CFA. Having CFI
instructions in function epilogue can cause incorrect CFA calculation rule
for some basic blocks. This can happen if, due to basic block reordering,
or the existence of multiple epilogue blocks, some of the blocks have wrong
cfa offset and register values set by the epilogue block above them.

Patch by Violeta Vukobrat.

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

llvm-svn: 306529

show more ...


# 95f24dca 24-Jun-2017 Hiroshi Inoue <inouehrs@jp.ibm.com>

[SelectionDAG] set dereferenceable flag when expanding memcpy/memmove

When SelectionDAG expands memcpy (or memmove) call into a sequence of load and store instructions, it disregards dereferenceable

[SelectionDAG] set dereferenceable flag when expanding memcpy/memmove

When SelectionDAG expands memcpy (or memmove) call into a sequence of load and store instructions, it disregards dereferenceable flag even the source pointer is known to be dereferenceable.
This results in an assertion failure if SelectionDAG commonizes a load instruction generated for memcpy with another load instruction for the source pointer.
This patch makes SelectionDAG to set the dereferenceable flag for the load instructions properly to avoid the assertion failure.

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

llvm-svn: 306209

show more ...


Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3
# 6bda14b3 06-Jun-2017 Chandler Carruth <chandlerc@gmail.com>

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...


Revision tags: llvmorg-4.0.1-rc2
# 4e9736b1 31-May-2017 Eugene Zelenko <eugene.zelenko@gmail.com>

[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 304265


# bc09894d 30-May-2017 Matthias Braun <matze@braunis.de>

MachineInstr: Do not skip dead def operands when printing.

This was introduced a long time ago in r86583 when regmask operands
didn't exist. Nowadays the behavior hurts more than it helps. This
remo

MachineInstr: Do not skip dead def operands when printing.

This was introduced a long time ago in r86583 when regmask operands
didn't exist. Nowadays the behavior hurts more than it helps. This
removes it.

llvm-svn: 304254

show more ...


# 06d6096e 28-Apr-2017 Adrian Prantl <aprantl@apple.com>

Cleanup: Use DIExpression::prepend in buildDbgValueForSpill(). (NFC)

llvm-svn: 301665


Revision tags: llvmorg-4.0.1-rc1
# 2deea187 22-Apr-2017 Daniel Sanders <daniel_l_sanders@apple.com>

[globalisel][tablegen] Revise API for ComplexPattern operands to improve flexibility.

Summary:
Some targets need to be able to do more complex rendering than just adding an
operand or two to an inst

[globalisel][tablegen] Revise API for ComplexPattern operands to improve flexibility.

Summary:
Some targets need to be able to do more complex rendering than just adding an
operand or two to an instruction. For example, it may need to insert an
instruction to extract a subreg first, or it may need to perform an operation
on the operand.

In SelectionDAG, targets would create SDNode's to achieve the desired effect
during the complex pattern predicate. This worked because SelectionDAG had a
form of garbage collection that would take care of SDNode's that were created
but not used due to a later predicate rejecting a match. This doesn't translate
well to GlobalISel and the churn was wasteful.

The API changes in this patch enable GlobalISel to accomplish the same thing
without the waste. The API is now:
InstructionSelector::OptionalComplexRendererFn selectArithImmed(MachineOperand &Root) const;
where Root is the root of the match. The return value can be omitted to
indicate that the predicate failed to match, or a function with the signature
ComplexRendererFn can be returned. For example:
return OptionalComplexRendererFn(
[=](MachineInstrBuilder &MIB) { MIB.addImm(Immed).addImm(ShVal); });
adds two immediate operands to the rendered instruction. Immed and ShVal are
captured from the predicate function.

As an added bonus, this also reduces the amount of information we need to
provide to GIComplexOperandMatcher.

Depends on D31418

Reviewers: aditya_nandakumar, t.p.northover, qcolombet, rovka, ab, javed.absar

Reviewed By: ab

Subscribers: dberris, kristof.beyls, igorb, llvm-commits

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

llvm-svn: 301079

show more ...


# 6825fb64 18-Apr-2017 Adrian Prantl <aprantl@apple.com>

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a regis

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a register
- consist of only a DW_OP_reg
2. Memory location descriptions
- describe the address of a variable
3. Implicit location descriptions
- describe the value of a variable
- end with DW_OP_stack_value & friends

The existing DwarfExpression code is pretty much ignorant of these
restrictions. This used to not matter because we only emitted very
short expressions that we happened to get right by accident. This
patch makes DwarfExpression aware of the rules defined by the DWARF
standard and now chooses the right kind of location description for
each expression being emitted.

This would have been an NFC commit (for the existing testsuite) if not
for the way that clang describes captured block variables. Based on
how the previous code in LLVM emitted locations, DW_OP_deref
operations that should have come at the end of the expression are put
at its beginning. Fixing this means changing the semantics of
DIExpression, so this patch bumps the version number of DIExpression
and implements a bitcode upgrade.

There are two major changes in this patch:

I had to fix the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.

When lowering a DBG_VALUE, the decision of whether to emit a register
location description or a memory location description depends on the
MachineLocation — register machine locations may get promoted to
memory locations based on their DIExpression. (Future) optimization
passes that want to salvage implicit debug location for variables may
do so by appending a DW_OP_stack_value. For example:
DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8
DBG_VALUE, RAX --> DW_OP_reg0 +0
DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0

All testcases that were modified were regenerated from clang. I also
added source-based testcases for each of these to the debuginfo-tests
repository over the last week to make sure that no synchronized bugs
slip in. The debuginfo-tests compile from source and run the debugger.

https://bugs.llvm.org/show_bug.cgi?id=32382
<rdar://problem/31205000>

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

llvm-svn: 300522

show more ...


# 89268b18 20-Mar-2017 Tim Northover <tnorthover@apple.com>

GlobalISel: allow quad-precision values to be dumped.

Otherwise the fallback path fails with an assertion on AAPCS AArch64 targets,
when "long double" is encountered.

llvm-svn: 298273


# 8a4bae99 14-Mar-2017 Daniel Sanders <daniel_l_sanders@apple.com>

[globalisel][tblgen] Add support for ComplexPatterns

Summary:
Adds a new kind of MachineOperand: MO_Placeholder.
This operand must not appear in the MIR and only exists as a way of
creating an 'unin

[globalisel][tblgen] Add support for ComplexPatterns

Summary:
Adds a new kind of MachineOperand: MO_Placeholder.
This operand must not appear in the MIR and only exists as a way of
creating an 'uninitialized' operand until a matcher function overwrites it.

Depends on D30046, D29712

Reviewers: t.p.northover, ab, rovka, aditya_nandakumar, javed.absar, qcolombet

Reviewed By: qcolombet

Subscribers: dberris, kristof.beyls, llvm-commits

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

llvm-svn: 297782

show more ...


12345678910>>...33