This commit implements the initial serialization of machine constant pools and
the constant pool index machine operands. The constant pool is serialized using
a YAML sequence of YAML mappings that represent the constant values.
The target-specific constant pool items aren't serialized by this commit.
Reviewers: Duncan P. N. Exon Smith
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242707 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1. Fix return value in `SparseBitVector::operator&=`.
2. Add checks if SBV is being assigned is invoking SBV.
Reviewers: dberlin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11342
Committed on behalf of sl@
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242693 91177308-0d34-0410-b5e6-96231b3b80d8
canFoldMemoryOperand is not actually used anywhere in the codebase - all existing users instead call foldMemoryOperand directly when they wish to fold and can correctly deduce what they need from the return value.
This patch removes the canFoldMemoryOperand base function and the target implementations; only x86 had a real (bit-rotted) implementation, although AMDGPU had a preparatory stub that had never needed to be completed.
Differential Revision: http://reviews.llvm.org/D11331
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242638 91177308-0d34-0410-b5e6-96231b3b80d8
directly model in the new PM.
This also was an incredibly brittle and expensive update API that was
never fully utilized by all the passes that claimed to preserve AA, nor
could it reasonably have been extended to all of them. Any number of
places add uses of values. If we ever wanted to reliably instrument
this, we would want a callback hook much like we have with ValueHandles,
but doing this for every use addition seems *extremely* expensive in
terms of compile time.
The only user of this update mechanism is GlobalsModRef. The idea of
using this to keep it up to date doesn't really work anyways as its
analysis requires a symmetric analysis of two different memory
locations. It would be very hard to make updates be sufficiently
rigorous to *guarantee* symmetric analysis in this way, and it pretty
certainly isn't true today.
However, folks have been using GMR with this update for a long time and
seem to not be hitting the issues. The reported issue that the update
hook fixes isn't even a problem any more as other changes to
GetUnderlyingObject worked around it, and that issue stemmed from *many*
years ago. As a consequence, a prior patch provided a flag to control
the unsafe behavior of GMR, and this patch removes the update mechanism
that has questionable compile-time tradeoffs and is causing problems
with moving to the new pass manager. Note the lack of test updates --
not one test in tree actually requires this update, even for a contrived
case.
All of this was extensively discussed on the dev list, this patch will
just enact what that discussion decides on. I'm sending it for review in
part to show what I'm planning, and in part to show the *amazing* amount
of work this avoids. Every call to the AA here is something like three
to six indirect function calls, which in the non-LTO pipeline never do
any work! =[
Differential Revision: http://reviews.llvm.org/D11214
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242605 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply r242500 now that the swift schedmodel includes LDRLIT.
This is mostly done to disable the PostRAScheduler which optimizes for
instruction latencies which isn't a good fit for out-of-order
architectures. This also allows to leave out the itinerary table in
swift in favor of the SchedModel ones.
This change leads to performance improvements/regressions by as much as
10% in some benchmarks, in fact we loose 0.4% performance over the
llvm-testsuite for reasons that appear to be unknown or out of the
compilers control. rdar://20803802 documents the investigation of
these effects.
While it is probably a good idea to perform the same switch for the
other ARM out-of-order CPUs, I limited this change to swift as I cannot
perform the benchmark verification on the other CPUs.
Differential Revision: http://reviews.llvm.org/D10513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242588 91177308-0d34-0410-b5e6-96231b3b80d8
This commit extends the interface provided by the AsmParser library by adding a
function that allows the user to parse a standalone contant value.
This change is useful for MIR serialization, as it will allow the MIR Parser to
parse the constant values in a machine constant pool.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10280
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242579 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r242500.
It broke some internal tests and Matthias asked me to revert it while he
is investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242553 91177308-0d34-0410-b5e6-96231b3b80d8
This is mostly done to disable the PostRAScheduler which optimizes for
instruction latencies which isn't a good fit for out-of-order
architectures. This also allows to leave out the itinerary table in
swift in favor of the SchedModel ones.
This change leads to performance improvements/regressions by as much as
10% in some benchmarks, in fact we loose 0.4% performance over the
llvm-testsuite for reasons that appear to be unknown or out of the
compilers control. rdar://20803802 documents the investigation of
these effects.
While it is probably a good idea to perform the same switch for the
other ARM out-of-order CPUs, I limited this change to swift as I cannot
perform the benchmark verification on the other CPUs.
Differential Revision: http://reviews.llvm.org/D10513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242500 91177308-0d34-0410-b5e6-96231b3b80d8
Those new constructors make it more natural to construct an object for a function. For example, previously to build a LoopInfo for a function, we need four statements:
DominatorTree DT;
LoopInfo LI;
DT.recalculate(F);
LI.analyze(DT);
Now we only need one statement:
LoopInfo LI(DominatorTree(F));
http://reviews.llvm.org/D11274
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242486 91177308-0d34-0410-b5e6-96231b3b80d8
llvm.eh.sjlj.setjmp was used as part of the SjLj exception handling
style but is also used in clang to implement __builtin_setjmp. The ARM
backend needs to output additional dispatch tables for the SjLj
exception handling style, these tables however can't be emitted if
llvm.eh.sjlj.setjmp is simply used for __builtin_setjmp and no actual
landing pad blocks exist.
To solve this issue a new llvm.eh.sjlj.setup_dispatch intrinsic is
introduced which is used instead of llvm.eh.sjlj.setjmp in the SjLj
exception handling lowering, so we can differentiate between the case
where we actually need to setup a dispatch table and the case where we
just need the __builtin_setjmp semantic.
Differential Revision: http://reviews.llvm.org/D9313
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242481 91177308-0d34-0410-b5e6-96231b3b80d8
Empty subranges are not allowed in a LiveInterval and must be removed
instead: Check this in the verifiers, put a reminder for this in the
comment of the shrinkToUses variant for a single lane and make it
automatic for the shrinkToUses variant for a LiveInterval.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242431 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.
Reviewers: lhames
Subscribers: echristo, llvm-commits, rafael, yaron.keren
Differential Revision: http://reviews.llvm.org/D11110
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242414 91177308-0d34-0410-b5e6-96231b3b80d8
This adds new intrinsics "*absdiff" for absolute difference ops to facilitate efficient code generation for "sum of absolute differences" operation.
The patch also contains the introduction of corresponding SDNodes and basic legalization support.Sanity of the generated code is tested on X86.
This is 1st of the three patches.
Patch by Shahid Asghar-ahmad!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242409 91177308-0d34-0410-b5e6-96231b3b80d8
This extension point allows passes to be executed right before the vectorizer
and other highly target specific optimizations are run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242389 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
The ExecutionEngine will act as an exception and will be unsafe to
be reused across context. We don't enforce this rule but undefined
behavior can occurs if the user tries to do it.
Reviewers: lhames
Subscribers: echristo, llvm-commits, rafael, yaron.keren
Differential Revision: http://reviews.llvm.org/D11110
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242387 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
This patch is quite boring overall, except for some uglyness in
ASMPrinter which has a getDataLayout function but has some clients
that use it without a Module (llmv-dsymutil, llvm-dwarfdump), so
some methods are taking a DataLayout as parameter.
Reviewers: echristo
Subscribers: yaron.keren, rafael, llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D11090
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242386 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: yaron.keren, rafael, llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D11079
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242385 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Because llvm-dsymutil is using ASMPrinter without any MachineFunction
of Module available.
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: yaron.keren, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D11078
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242384 91177308-0d34-0410-b5e6-96231b3b80d8
This is made a static public member function to allow the transition of
this logic from LAA to LoopDistribution. (Technically, it could be an
implementation-local static function but then it would not be accessible
from LoopDistribution.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242376 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the changes to the C API LLVMBuildLandingPad that were part of
the personality function move. We now set the personality on the parent
function when the C API attempts to construct a landingpad with a
personality.
This reverts commit r240010.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242372 91177308-0d34-0410-b5e6-96231b3b80d8
The jump table info is serialized using a YAML mapping that contains its kind
and a YAML sequence of jump table entries. A jump table entry is a YAML mapping
that has an ID and an inline YAML sequence of machine basic block references.
The testcase 'CodeGen/MIR/X86/jump-table-info.mir' doesn't have any instructions
because one of them contains a jump table index operand. The jump table index
operands will be serialized in a follow up patch, and the appropriate
instructions will be added to this testcase.
Reviewers: Duncan P. N. Exon Smith
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242357 91177308-0d34-0410-b5e6-96231b3b80d8
Pass a const reference to LiveRegMatrix to getRegAllocationHints()
because some targets can prodive better hints if they can test whether a
physreg has been used for register allocation yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242340 91177308-0d34-0410-b5e6-96231b3b80d8
This commit serializes the references to the named LLVM alloca instructions from
the stack objects in the machine frame info. This commit adds a field 'Name' to
the struct 'yaml::MachineStackObject'. This new field is used to store the name
of the alloca instruction when the alloca is present and when it has a name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242339 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary prerequisite for bootstrapping the emission
of debug info inside modules.
- Adds a FlagExternalTypeRef to DICompositeType.
External types must have a unique identifier.
- External type references are emitted using a forward declaration
with a DW_AT_signature([DW_FORM_ref_sig8]) based on the UID.
http://reviews.llvm.org/D9612
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242302 91177308-0d34-0410-b5e6-96231b3b80d8
- Teaches the ValueTracker in the PeepholeOptimizer to look through PHI
instructions.
- Add findNextSourceAndRewritePHI method to lookup into multiple sources
returnted by the ValueTracker and rewrite PHIs with new sources.
With these changes we can find more register sources and rewrite more
copies to allow coaslescing of bitcast instructions. Hence, we eliminate
unnecessary VR64 <-> GR64 copies in x86, but it could be extended to
other archs by marking "isBitcast" on target specific instructions. The
x86 example follows:
A:
psllq %mm1, %mm0
movd %mm0, %r9
jmp C
B:
por %mm1, %mm0
movd %mm0, %r9
jmp C
C:
movd %r9, %mm0
pshufw $238, %mm0, %mm0
Becomes:
A:
psllq %mm1, %mm0
jmp C
B:
por %mm1, %mm0
jmp C
C:
pshufw $238, %mm0, %mm0
Differential Revision: http://reviews.llvm.org/D11197
rdar://problem/20404526
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242295 91177308-0d34-0410-b5e6-96231b3b80d8
MachineCombiner predicated its use of scheduling-based metrics on
hasInstrSchedModel(), but useful conclusions can be drawn from pipeline
itineraries as well. Almost all of the logic (except for resource tracking in
preservesResourceLen) can be used if we have an itinerary, so enable it in that
case as well.
This will be used by the PowerPC backend in an upcoming commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242277 91177308-0d34-0410-b5e6-96231b3b80d8
When FixedLenDecoder matches an input bitpattern of form [01]+ with an
instruction bitpattern of form [01?]+ (where 0/1 are static bits and ? are
mixed/variable bits) it passes the input bitpattern to a specific instruction
decoder method which then makes a final decision whether the bitpattern is a
valid instruction or not. This means the decoder must handle all possible
values of the variable bits which sometimes leads to opcode rewrites in the
decoder method when the instructions are not fully orthogonal.
The patch provides a way for the decoder method to say that when it returns
Fail it does not necessarily mean the bitpattern is invalid, but rather that
the bitpattern is definitely not an instruction that is recognized by the
decoder method. The decoder can then try to match the input bitpattern with
other possible instruction bitpatterns.
For example, this allows to solve a situation on AArch64 where the `MSR
(immediate)` instruction has form:
1101 0101 0000 0??? 0100 ???? ???1 1111
but not all values of the ? bits are allowed. The rejected values should be
handled by the `extended MSR (register)` instruction:
1101 0101 000? ???? ???? ???? ???? ????
The decoder will first try to decode an input bitpattern that matches both
bitpatterns as `MSR (immediate)` but currently this puts the decoder method of
`MSR (immediate)` into a situation when it must be able to decode all possible
values of the ? bits, i.e. it would need to rewrite the instruction to `MSR
(register)` when it is not `MSR (immediate)`.
The patch allows to specify that the decoder method cannot determine if the
instruction is valid for all variable values. The decoder method can simply
return Fail when it knows it is definitely not `MSR (immediate)`. The decoder
will then backtrack the decoding and find that it can match the input
bitpattern with the more generic `MSR (register)` bitpattern too.
Differential Revision: http://reviews.llvm.org/D7174
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242274 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful when we want to do block frequency analysis
conditionally (e.g. only in PGO mode) but don't want to add
one more pass dependence.
Patch by congh.
Approved by dexonsmith.
Differential Revision: http://reviews.llvm.org/D11196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242248 91177308-0d34-0410-b5e6-96231b3b80d8
