| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
We used to detect loads feeding fp instructions, but we were
failing to take into account cases where this happens through copies.
For instance, loads can fed copies coming from the ABI lowering
of floating point arguments/results.
llvm-svn: 318589
|
|
|
|
|
|
|
|
|
| |
We used to detect that stores were fed by fp instructions, but we were
failing to take into account cases where this happens through copies.
For instance, stores can be fed by copies coming from the ABI lowering
of floating point arguments.
llvm-svn: 318588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mappings
Instead of asserting that the type sizes are exactly equal, we check
that the new size is big enough to contain the original type.
We have to relax this constrain because, right now, we sometimes
specify that things that are smaller than a storage type are legal
instead of widening everything to the size of a storage type.
E.g., we say that G_AND s16 is legal and we map that on GPR32.
This is something we may revisit in the future (either by changing
the legalization process or keeping track separately of the storage
size and the size of the type), but let us reflect the reality of
the situation for now.
llvm-svn: 318587
|
|
|
|
|
|
|
|
|
| |
cross copies
Turns out this copies can actually occur because of the way we lower the
ABI for half.
llvm-svn: 318586
|
|
|
|
| |
llvm-svn: 318584
|
|
|
|
|
|
|
| |
By having an UTF-16 version we avoid some code duplication in calling
GetFinalPathNameByHandleW.
llvm-svn: 318583
|
|
|
|
|
|
|
|
|
| |
We were not doing that for large shadow granularity. Also add more
stack frame layout tests for large shadow granularity.
Differential Revision: https://reviews.llvm.org/D39475
llvm-svn: 318581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert the following commits:
r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22.
r318235 [asan] Prevent rematerialization of &__asan_shadow.
r317948 [sanitizer] Remove unnecessary attribute hidden.
r317943 [asan] Use dynamic shadow on 32-bit Android.
MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer
that may overlap with the address range that we plan to use for the
dynamic shadow mapping. This is causing random startup crashes.
llvm-svn: 318575
|
|
|
|
|
|
|
|
|
|
| |
true.
Differential Revision: https://reviews.llvm.org/D39737
This is the second attempt to commit this. The test was broken on Linux in the first attempt.
llvm-svn: 318560
|
|
|
|
|
|
|
|
|
|
| |
This is mostly moving VMEM clause breaking into
the hazard recognizer. Also move another hazard
currently handled in the waitcnt pass.
Also stops breaking clauses unless xnack is enabled.
llvm-svn: 318557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fix PR35342 by replacing only the current use with undef in unreachable blocks.
Reviewers: efriedma, mcrosier, igor-laevsky
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40184
llvm-svn: 318551
|
|
|
|
|
|
|
|
|
| |
This move some of the complexity over to the lower level TempFile.
It also makes it a bit more explicit where errors are ignored since we
now have a call to consumeError.
llvm-svn: 318550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
making it no longer even remotely simple.
The pass will now be more of a "full loop unswitching" pass rather than
anything substantively simpler than any other approach. I plan to rename
it accordingly once the dust settles.
The key ideas of the new loop unswitcher are carried over for
non-trivial unswitching:
1) Fully unswitch a branch or switch instruction from inside of a loop to
outside of it.
2) Update the CFG and IR. This avoids needing to "remember" the
unswitched branches as well as avoiding excessively cloning and
reliance on complex parts of simplify-cfg to cleanup the cfg.
3) Update the analyses (where we can) rather than just blowing them away
or relying on something else updating them.
Sadly, #3 is somewhat compromised here as the dominator tree updates
were too complex for me to want to reason about. I will need to make
another attempt to do this now that we have a nice dynamic update API
for dominators. However, we do adhere to #3 w.r.t. LoopInfo.
This approach also adds an important principls specific to non-trivial
unswitching: not *all* of the loop will be duplicated when unswitching.
This fact allows us to compute the cost in terms of how much *duplicate*
code is inserted rather than just on raw size. Unswitching conditions
which essentialy partition loops will work regardless of the total loop
size.
Some remaining issues that I will be addressing in subsequent commits:
- Handling unstructured control flow.
- Unswitching 'switch' cases instead of just branches.
- Moving to the dynamic update API for dominators.
Some high-level, interesting limitationsV that folks might want to push
on as follow-ups but that I don't have any immediate plans around:
- We could be much more clever about not cloning things that will be
deleted. In fact, we should be able to delete *nothing* and do
a minimal number of clones.
- There are many more interesting selection criteria for which branch to
unswitch that we might want to look at. One that I'm interested in
particularly are a set of conditions which all exit the loop and which
can be merged into a single unswitched test of them.
Differential revision: https://reviews.llvm.org/D34200
llvm-svn: 318549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a vreg's bank is specified in the registers block and one of its
defs or uses also specifies the bank, we end up checking that the
RegBank is equal to diagnose conflicting banks. The problem comes up
for generic vregs, where we weren't fully initializing the VRegInfo
when parsing the registers block, so we'd end up comparing a null
pointer to uninitialized memory.
This fixes a non-deterministic failure when round tripping through MIR
with generic vregs.
llvm-svn: 318543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assertion was introduced in r317853 but there are cases when a call
isn't handled either as direct or indirect. In this case we add a
reference graph edge but not a call graph edge.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D40056
llvm-svn: 318540
|
|
|
|
|
|
|
|
|
|
| |
set to true."
This reverts commit r318528.
MC/AsmParser/preserve-comments-crlf.s fails on linux.
llvm-svn: 318533
|
|
|
|
|
|
| |
Improve the accuracy of the model by specifying the proper number of uops.
llvm-svn: 318531
|
|
|
|
|
|
|
|
| |
true.
Differential Revision: https://reviews.llvm.org/D39737
llvm-svn: 318528
|
|
|
|
|
|
|
|
|
|
| |
See bug 35148: https://bugs.llvm.org//show_bug.cgi?id=35148
Reviewers: tamazov, SamWot, arsenm
Differential Revision: https://reviews.llvm.org/D39492
llvm-svn: 318526
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed broken comparison.
borked by: rL284966 (see: https://reviews.llvm.org/D25730).
Differential Revision: https://reviews.llvm.org/D40119
This is a second attempt to commit this.
The first attempt broke lld and gold tests that had been written against
the incorrect behaivour.
llvm-svn: 318524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enabling and using dwarf exceptions seems like an easier path
to take, than to make the COFF/ARM backend output EHABI directives.
Previously, no EH model was enabled at all on this target.
There's no point in setting UseIntegratedAssembler to false since
GNU binutils doesn't support Windows on ARM, and since we don't
need to support external assembler, we don't need to use register
numbers in cfi directives.
Differential Revision: https://reviews.llvm.org/D39532
llvm-svn: 318510
|
|
|
|
|
|
|
|
|
|
| |
handle nodes with chain outputs.
Previously we were assuming all results were vectors and calling SetWidenedVector, but if its a chain result we should just replace uses instead.
This fixes an error found by expensive checks after r318368.
llvm-svn: 318509
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic of replacing of a couple `RANGE_CHECK_LOWER + RANGE_CHECK_UPPER`
into `RANGE_CHECK_BOTH` in fact duplicates the logic of range intersection which
happens when we calculate safe iteration space. Effectively, the result of intersection of
these ranges doesn't differ from the range of merged range check.
We chose to remove duplicating logic in favor of code simplicity.
Differential Revision: https://reviews.llvm.org/D39589
llvm-svn: 318508
|
|
|
|
| |
llvm-svn: 318506
|
|
|
|
|
|
|
|
| |
This was completely ignoring subregisters,
so was not very useful. Also only break them
if xnack is actually enabled.
llvm-svn: 318505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TransferDbgValues (capital 'T') is wired into ReplaceAllUsesWith, and
transferDbgValues (lowercase 't') is used elsewhere (e.g in Legalize).
Both functions should be doing the exact same thing. This patch
consolidates the logic into one place.
This was reverted in r318455 because some newly introduced asserts,
which I thought were NFC, were firing. I filed PR35338. For now I've
weakened the asserts.
Testing: check-llvm, check-clang, and a stage2 Rel+Deb build of clang
Differential Revision: https://reviews.llvm.org/D40104
llvm-svn: 318498
|
|
|
|
|
|
|
|
| |
All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
|
|
|
|
|
|
|
|
|
|
| |
It turns out this #include isn't used from Host.h anyway,
but by having it it causes circular include dependencies.
This issues only surfaced while I was working on a separate
patch, so I'm submitting this first so that it's independent
of the other, unrelated patch.
llvm-svn: 318489
|
|
|
|
| |
llvm-svn: 318487
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iterator to walk the list which keeps changing inside the loop. When the
UseList contains several uses with the same user, we end processing the same
user more than once, which leads to an assert.
With this fix, unique users are saved and processed later to avoid
processing duplicates.
Differential Revision: https://reviews.llvm.org/D39864
llvm-svn: 318477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
't' constraint normally only accepts f32 operands, but for VCVT the
operands can be i32. LLVM is overly restrictive and rejects asm like:
float foo() {
float result;
__asm__ __volatile__(
"vcvt.f32.s32 %[result], %[arg1]\n"
: [result]"=t"(result)
: [arg1]"t"(0x01020304) );
return result;
}
Relax the value type for 't' constraint to either f32 or i32.
Differential Revision: https://reviews.llvm.org/D40137
llvm-svn: 318472
|
|
|
|
|
|
|
|
|
|
| |
Only do this pre-legalize in case we're using the sign extend to legalize for KNL.
This recovers all of the tests that changed when I stopped SelectionDAGBuilder from deleting sign extends.
There's more work that could be done here particularly to fix the i8->i64 test case that experienced split.
llvm-svn: 318468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SelectionDAGBuilder.
The sign extend might be from an i16 or i8 type and was inserted by InstCombine to match the pointer width. X86 gather legalization isn't currently detecting this to reinsert a sign extend to make things legal.
It's a bit weird for the SelectionDAGBuilder to do this kind of optimization in the first place. With this removed we can at least lean on InstCombine somewhat to ensure the index is i32 or i64.
I'll work on trying to recover some of the test cases by removing sign extends in the backend when its safe to do so with an understanding of the current legalizer capabilities.
This should fix PR30690.
llvm-svn: 318466
|
|
|
|
|
|
|
|
|
| |
Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocateMappedMemory method is updated to request full permissions for memory
blocks so that they can be marked executable later.
llvm-svn: 318464
|
|
|
|
|
|
|
| |
This was broken when building a 32-bit native toolchain, as
shifting a size_t right by 32 is UB when sizeof(size_t) == 8.
llvm-svn: 318462
|
|
|
|
|
|
|
| |
This one requires a new small feature in TempFile: the ability to keep
the temporary file with the temporary name.
llvm-svn: 318458
|
|
|
|
|
|
|
|
|
| |
This reverts commit r318448. It looks like some of the asserts need to
be weakened.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/16296
llvm-svn: 318455
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: asb
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, llvm-commits
Differential Revision: https://reviews.llvm.org/D40145
llvm-svn: 318454
|
|
|
|
|
|
|
|
|
|
| |
than 64-bits before Legalize.
The wider element type will normally cause legalize to try to split and scalarize the gather/scatter, but we can't handle that. Instead, truncate the index early so the gather/scatter node is insulated from the legalization.
This really shouldn't happen in practice since InstCombine will normalize index types to the same size as pointers.
llvm-svn: 318452
|
|
|
|
| |
llvm-svn: 318451
|
|
|
|
| |
llvm-svn: 318450
|
|
|
|
|
|
|
|
|
|
|
|
| |
TransferDbgValues (capital 'T') is wired into ReplaceAllUsesWith, and
transferDbgValues (lowercase 't') is used elsewhere (e.g in Legalize).
Both functions should be doing the exact same thing. This patch
consolidates the logic into one place.
Differential Revision: https://reviews.llvm.org/D40104
llvm-svn: 318448
|
|
|
|
| |
llvm-svn: 318447
|
|
|
|
| |
llvm-svn: 318444
|
|
|
|
|
|
|
|
| |
lib/Target/ARC/ARCISelLowering.cpp:490:22: error: use of overloaded operator '<<' is ambiguous (with operand types 'llvm::raw_ostream' and 'llvm::MVT::SimpleValueType')
<< RegVT.getSimpleVT().SimpleTy << "\n");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
llvm-svn: 318443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, it prints the backward branch offset as unsigned value
like below:
7: 7d 34 0b 00 00 00 00 00 if r4 s>= r3 goto 11 <LBB0_3>
8: b7 00 00 00 00 00 00 00 r0 = 0
LBB0_2:
9: 07 00 00 00 01 00 00 00 r0 += 1
......
17: bf 31 00 00 00 00 00 00 r1 = r3
18: 6d 32 f6 ff 00 00 00 00 if r2 s> r3 goto 65526 <LBB0_3+0x7FFB0>
The correct print insn 18 should be:
18: 6d 32 f6 ff 00 00 00 00 if r2 s> r3 goto -10 <LBB0_2>
To provide better clarity and be consistent with kernel verifier output,
the insn 7 output is changed to the following with "+" added to
non-negative branch offset:
7: 7d 34 0b 00 00 00 00 00 if r4 s>= r3 goto +11 <LBB0_3>
Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318442
|
|
|
|
|
|
|
| |
Also update a comment about the usage of RegisterTarget() that didn't mention
the new argument.
llvm-svn: 318441
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: asb, apazos, mgrang
Reviewed By: mgrang
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, llvm-commits
Differential Revision: https://reviews.llvm.org/D40139
llvm-svn: 318437
|
|
|
|
|
|
|
|
| |
This patch changes all i32 constant in store instruction to i64 with truncation, to increase the chance that the referenced constant can be shared with other i64 constant.
Differential Revision: https://reviews.llvm.org/D39352
llvm-svn: 318436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change introduces a `DynamicSymbols` field to the ELF specific YAML
supported by `yaml2obj` and `obj2yaml`. This grouping of symbols provides a way
to represent ELF dynamic symbols. The `DynamicSymbols` structure is identical to
the existing `Symbols`.
Reviewers: compnerd, jakehehrlich, silvas
Reviewed By: silvas
Subscribers: silvas, jakehehrlich, llvm-commits
Differential Revision: https://reviews.llvm.org/D39582
llvm-svn: 318433
|