| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This reverts commit r269425, as it fails on Windows (Thumb only).
llvm-svn: 269451
|
| |
|
|
| |
llvm-svn: 269449
|
| |
|
|
| |
llvm-svn: 269447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro,
but not all of them.
Implementation contains following rules:
- floating point immediates are always printed as decimal
- signed integer immediates are printed depends on flag settings
(for negative values 'formatImm' macro prints the value as i.e -0x01
which may be convenient when imm is an address or offset)
- logical immediates are always printed as hex
- the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex
- the 64-bit immedaite in exception generation instructions like:
brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex
- the rest of immediates is printed depends on availability
of -print-imm-hex
Signed-off-by: Maciej Gabka <maciej.gabka@arm.com>
Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com>
Differential Revision: http://reviews.llvm.org/D16929
llvm-svn: 269446
|
| |
|
|
|
|
| |
This will make it easier to write FileCheck tests.
llvm-svn: 269444
|
| |
|
|
|
|
|
|
| |
This patch adds basic support for MachO::load_command. Load command types and sizes are encoded in the YAML and expanded back into MachO.
The YAML doesn't yet support load command structs, that is coming next. In the meantime as a temporary measure when writing MachO files the load commands are padded with zeros so that the generated binary is valid.
llvm-svn: 269442
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Enhancement to: http://reviews.llvm.org/rL269426
With discussion in: http://reviews.llvm.org/D17859
This should complete the fixes for: PR26701, PR26819:
https://llvm.org/bugs/show_bug.cgi?id=26701
https://llvm.org/bugs/show_bug.cgi?id=26819
llvm-svn: 269439
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: When the MCJIT generates ELF code, some DWARF data requires 64-bit PC-relative relocation (R_390_PC64). This patch adds support for R_390_PC64 relocation to RuntimeDyld::resolveSystemZRelocation, to avoid an assertion failure.
Reviewers: uweigand
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20033
llvm-svn: 269436
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fix the bug in isProfitableToUseMemset() where MaxIntSize shoule be in byte, not bit.
Reviewers: arsenm, joker.eph, mcrosier
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20176
llvm-svn: 269433
|
| |
|
|
|
|
|
|
| |
This reverts commit r269428, as it breaks the LLDB build. We need to
understand how to change LLDB in the same way as LLC before landing this
again.
llvm-svn: 269432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without a diagnostic handler installed, llc's behaviour is to exit on the first
error that it encounters. This is very different from the behaviour of clang
and other front ends, which try to gather as many errors as possible before
exiting.
This commit adds a diagnostic handler to llc, allowing it to find and report
more than one error. The old behaviour is preserved under a flag (-exit-on-error).
Some of the tests fail with the new diagnostic handler, so they have to use the
new flag in order to run under the previous behaviour. Some of these are known
bugs, others need further investigation. Ideally, we should fix the tests and
remove the flag at some point in the future.
Patch by Diana Picus.
llvm-svn: 269428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR26701, PR26819)
*We don't currently handle the edge case constants (min/max values), so it's not a complete
canonicalization.
To fully solve the motivating bugs, we need to enhance this to recognize a zero vector
too because that's a ConstantAggregateZero which is a ConstantData, not a ConstantVector
or a ConstantDataVector.
Differential Revision: http://reviews.llvm.org/D17859
llvm-svn: 269426
|
| |
|
|
|
|
|
|
| |
These tests were sitting in Phab for many months. They're good tests and should be in.
Patch by Charlie Turner.
llvm-svn: 269425
|
| |
|
|
|
|
|
|
| |
going haywire
I'm not going to regenerate these anytime soon but do have some diffs to apply that I'd like to do with update_llc_test_checks
llvm-svn: 269420
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18725
llvm-svn: 269413
|
| |
|
|
|
|
|
|
|
|
|
|
| |
evaluation exposed by r268900.
It's not entirely clear why R_MICROMIPS_(GOT|HI16|LO16) are evaluated
incorrectly in a small number of the LNT tests at this point. However, it's not
related to the STO_MIPS_MICROMIPS issue.
At this point all the microMIPS-related changes of r268900 have been reverted.
llvm-svn: 269410
|
| |
|
|
|
|
|
|
| |
MULSAQ_S.W.PH instructions
Differential Revision: http://reviews.llvm.org/D14117
llvm-svn: 269408
|
| |
|
|
|
|
|
|
|
|
|
| |
tracking system during the full unroll heuristic analysis that avoids counting any instruction cost until that instruction becomes "live" through a side-effect or use outside the..."
This reverts commit r269388.
It caused some bots to fail, I'm reverting it until I investigate the
issue.
llvm-svn: 269395
|
| |
|
|
|
|
|
|
|
|
| |
We only really need this to be true for SIFixSGPRCopies.
I'm not sure there's any way this could happen before that point.
Fixes a case where MachineCSE could introduce a cross block
scc use.
llvm-svn: 269391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
system during the full unroll heuristic analysis that avoids counting any instruction cost until that instruction becomes "live" through a side-effect or use outside the...
Summary:
...loop after the last iteration.
This is really hard to do correctly. The core problem is that we need to
model liveness through the induction PHIs from iteration to iteration in
order to get the correct results, and we need to correctly de-duplicate
the common subgraphs of instructions feeding some subset of the
induction PHIs. All of this can be driven either from a side effect at
some iteration or from the loop values used after the loop finishes.
This patch implements this by storing the forward-propagating analysis
of each instruction in a cache to recall whether it was free and whether
it has become live and thus counted toward the total unroll cost. Then,
at each sink for a value in the loop, we recursively walk back through
every value that feeds the sink, including looping back through the
iterations as needed, until we have marked the entire input graph as
live. Because we cache this, we never visit instructions more than twice
-- once when we analyze them and put them into the cache, and once when
we count their cost towards the unrolled loop. Also, because the cache
is only two bits and because we are dealing with relatively small
iteration counts, we can store all of this very densely in memory to
avoid this from becoming an excessively slow analysis.
The code here is still pretty gross. I would appreciate suggestions
about better ways to factor or split this up, I've stared too long at
the algorithmic side to really have a good sense of what the design
should probably look at.
Also, it might seem like we should do all of this bottom-up, but I think
that is a red herring. Specifically, the simplification power is *much*
greater working top-down. We can forward propagate very effectively,
even across strange and interesting recurrances around the backedge.
Because we use data to propagate, this doesn't cause a state space
explosion. Doing this level of constant folding, etc, would be very
expensive to do bottom-up because it wouldn't be until the last moment
that you could collapse everything. The current solution is essentially
a top-down simplification with a bottom-up cost accounting which seems
to get the best of both worlds. It makes the simplification incremental
and powerful while leaving everything dead until we *know* it is needed.
Finally, a core property of this approach is its *monotonicity*. At all
times, the current UnrolledCost is a conservatively low estimate. This
ensures that we will never early-exit from the analysis due to exceeding
a threshold when if we had continued, the cost would have gone back
below the threshold. These kinds of bugs can cause incredibly hard to
track down random changes to behavior.
We could use a techinque similar (but much simpler) within the inliner
as well to avoid considering speculated code in the inline cost.
Reviewers: chandlerc
Subscribers: sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D11758
llvm-svn: 269388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplified.
Summary:
Currently we consider such instructions as simplified, which is incorrect,
because if their user isn't simplified, we can't actually simplify them too.
This biases our estimates of profitability: for instance the analyzer expects
much more gains from unrolling memcpy loops than there actually are.
Reviewers: hfinkel, chandlerc
Subscribers: mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17365
llvm-svn: 269387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In verbose mode, we emit a warning if the DWOId of a skeleton CU
mismatches the DWOId of the referenced module. This patch updates the
cached DWOId after a module has been loaded to the DWOId of the module
on disk (instead of storing the DWOId we expected to load). This
allows us to correctly emit the mismatch warning for all subsequent
object files that want to import the same module. This patch also
ensures both warnings are only emitted in verbose mode.
rdar://problem/26214027
llvm-svn: 269383
|
| |
|
|
|
|
| |
Also stop visiting type records when we encounter an error.
llvm-svn: 269374
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change implements the transformation in processInstruction() for the
LDR rt, =expression to MOV rt, expression when the expression can be evaluated
and can fit into the immediate field of the MOV or a MVN.
Across the ARM and Thumb instruction sets there are several cases to consider,
each with a different range of representatble constants.
In ARM we have:
* Modified immediate (All ARM architectures)
* MOVW (v6t2 and above)
In Thumb we have:
* Modified immediate (v6t2, v7m and v8m.mainline)
* MOVW (v6t2, v7m, v8.mainline and v8m.baseline)
* Narrow Thumb MOV that can be used in an IT block (non flag-setting)
If the immediate fits any of the available alternatives then we make the transformation.
Fixes 25722.
Patch by Peter Smith.
llvm-svn: 269354
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Alter instances in the test-suite that use immediates that can be represented
in the immediate field of a MOV. The reason for doing this is that when the
LDR rt,=imm transformation to MOV rt, imm the existing tests do not need to
be modified.
Required by the patch that fixes PR25722.
Patch by Peter Smith.
llvm-svn: 269353
|
| |
|
|
|
|
|
|
| |
This reverts commit r269016 and also the follow-up commit r269020.
This patch caused PR27705.
llvm-svn: 269344
|
| |
|
|
|
|
| |
llvm-dwp
llvm-svn: 269339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit AllRegs:
SSE: xmm0-xmm7
AVX: ymm0-ymm7
AVX512: zmm0-zmm7 + k0-k7
64-bit AllRegs:
SSE: xmm0-xmm15
AVX: ymm0-ymm15
AVX512: zmm0-zmm31 + k0-k7
Differential Revision: http://reviews.llvm.org/D20142
llvm-svn: 269337
|
| |
|
|
| |
llvm-svn: 269328
|
| |
|
|
|
|
| |
I've added the reserved field as an "optional" in YAML, but I've added asserts in the yaml2macho code to enforce that the field is present in mach_header_64, but not in mach_header.
llvm-svn: 269320
|
| |
|
|
|
|
|
|
| |
With this change obj2yaml and yaml2obj can now round-trip mach_headers.
This change also adds ObjectYAML/MachO tests.
llvm-svn: 269314
|
| |
|
|
| |
llvm-svn: 269312
|
| |
|
|
| |
llvm-svn: 269308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offset is in range.
Summary:
This expands on r269179 to fix an additional case that was not covered by our
tests. The assembler temporary is not needed when the .cprestore offset fits
inside a simm16 and it is not an error to use it inside a '.set noat' in this
case.
Reviewers: emaste, seanbruno, sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20199
llvm-svn: 269295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposed by r268900
As explained in r269196, microMIPS has a special case that is not correctly
implemented in LLVM. If we have a symbol 'foo' which is equivalent to
'.text+0x10'. The value of an R_MICROMIPS_LO16 relocation using 'foo' is
'foo+0x11' and not 'foo+0x10'. The in-place addend should therefore be 0x11.
This commit reverts a little more of the effect of r268900 by keeping the
symbol when the STO_MIPS_MICROMIPS flag is set for R_MIPS_GPREL32 relocations.
This fixes SingleSource/UnitTests/2003-08-11-VaListArg, and
SingleSource/UnitTests/2003-05-07-VarArgs for microMIPS.
I believe there are additional relocations that have the same issue (e.g.
R_MIPS_64, and R_MIPS_GPREL16) but for now I'm focusing on restoring our
internal buildbots back to the green state we had in r268899.
llvm-svn: 269294
|
| |
|
|
|
|
|
| |
The EXTR combine has been in tree for over 2 years without complain, so go ahead
and remove the option.
llvm-svn: 269292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and BITREVERSE stages
For BITREVERSE, bit shifting/masking every bit in a vector element is a very lengthy procedure.
If the input vector type is a whole multiple of bytes wide then we can split this into a BSWAP shuffle stage (to reverse at the byte level) and then a BITREVERSE stage applied to each byte. Most vector capable targets can efficiently BSWAP using shuffles resulting in a considerable reduction in instructions.
With this patch targets would only need to implement a target specific vXi8 BITREVERSE implementation to efficiently reverse most legal vector types.
Differential Revision: http://reviews.llvm.org/D19978
llvm-svn: 269290
|
| |
|
|
|
|
| |
This reverts commit r269176 as it caused test-suite failure.
llvm-svn: 269287
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: sdardis
Subscribers: petarj, mpf, dsanders, spetrovic, llvm-commits, sdardis
Differential Revision: http://reviews.llvm.org/D18899
llvm-svn: 269283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
needsRelocateWithSymbol()
Summary:
This eliminates the default case for N64 that was left out of r269047.
The change to R_MIPS_SUB is needed in this patch to make this testable since
%lo(%neg(%gp_rel(foo))) and %hi(%neg(%gp_rel(foo))) remain the only ways to get
a compound relocation from the assembler.
Reviewers: sdardis, rafael
Subscribers: dsanders, llvm-commits, sdardis
Differential Revision: http://reviews.llvm.org/D20097
llvm-svn: 269280
|
| |
|
|
| |
llvm-svn: 269273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While promoting nodes in PPCTargetLowering::DAGCombineExtBoolTrunc, it is
possible for one of the nodes to be replaced by another. To make sure we do not
visit the deleted nodes, and to make sure we visit the replacement nodes, use a
list of HandleSDNodes to track the to-be-promoted nodes during the promotion
process.
The same fix has been applied to the analogous code in
PPCTargetLowering::DAGCombineTruncBoolExt.
Fixes PR26985.
llvm-svn: 269272
|
| |
|
|
|
|
|
|
|
| |
Shifts beyond the bitwidth are undef but SCCP resolved them to zero.
Instead, DTRT and resolve them to undef.
This reimplements the transform which caused PR27712.
llvm-svn: 269269
|
| |
|
|
|
|
| |
Enabled by -force-precise-rotation-cost option
llvm-svn: 269267
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The promote alloca pass would attempt to promote an alloca with
a select, icmp, or phi user, even though the other operand was
from a non-promotable source, producing a select on two different
pointer types.
Only do this if we know that both operands derive from the same
alloca. In the future we should be able to relax this to an alloca
which will also be promoted.
llvm-svn: 269265
|
| |
|
|
| |
llvm-svn: 269263
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new verifier rule lets us unambigously pick a calling convention
when creating a new declaration for
`@llvm.experimental.deoptimize.<ty>`. It is also congruent with our
lowering strategy -- since all calls to `@llvm.experimental.deoptimize`
are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce
a unique calling convention.
Some of the tests that were breaking this verifier rule have had to be
split up into different .ll files.
The inliner was violating this rule as well, and has been fixed to avoid
producing invalid IR.
llvm-svn: 269261
|
| |
|
|
|
|
|
|
| |
defined."
This reverts commit r269105 as it caused PR27712.
llvm-svn: 269252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to fix the bug in https://llvm.org/bugs/show_bug.cgi?id=27612.
When spill is hoisted to a BB with landingpad successor, and if the VNI
of the spill reg lives into the landingpad successor, the spill should be
inserted before the call which may throw exception. InsertPointAnalysis
is used to compute the safe insert point.
http://reviews.llvm.org/D20027 is a preparing patch for this patch.
Differential Revision: http://reviews.llvm.org/D19884.
llvm-svn: 269249
|
| |
|
|
| |
llvm-svn: 269241
|