| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The opcode for the optimized branch does not depend on the size
of the activate bits in the AND masks, but the AND opcode itself.
Indeed, we need to use a X or W variant based on the AND variant
not based on whether the mask fits into the related variant.
Otherwise, we may end up using the W variant of the optimized branch
for 64-bit register inputs!
This fixes the last make check verifier issues for AArch64: PR27479.
llvm-svn: 267206
|
| |
|
|
| |
llvm-svn: 267199
|
| |
|
|
|
|
| |
This will make the port to the new PM easier to follow.
llvm-svn: 267198
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change will shorten memset if the beginning of memset is overwritten by later stores.
Reviewers: hfinkel, eeckstein, dberlin, mcrosier
Subscribers: mgrang, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18906
llvm-svn: 267197
|
| |
|
|
|
|
|
| |
Also add a very basic test, since apparently there aren't any tests
for DCE whatsoever to add the new pass version to.
llvm-svn: 267196
|
| |
|
|
| |
llvm-svn: 267191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
E.g. for:
!1 = {"llvm.distribute", i32 1}
it now returns the MDOperand for 1.
I will use this in LoopDistribution to check the value of the metadata.
Note that the change is backward-compatible with its current use in
LoopVersioningLICM. An Optional implicitly converts to a bool depending
whether it contains a value or not.
llvm-svn: 267190
|
| |
|
|
|
|
|
|
|
| |
Avoid quadratic complexity in unusually large basic blocks by limiting
the size of the ready lists.
Differential Revision: http://reviews.llvm.org/D19349
llvm-svn: 267189
|
| |
|
|
| |
llvm-svn: 267187
|
| |
|
|
|
|
|
|
| |
declared as a definition.
This fixes the machine verifier error for CodeGen/AArch64/nzcv-save.ll.
llvm-svn: 267185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to simply set the kill flags to true when transforming a scalar
instruction to a vector one.
SrcScalar1 = copy SrcVector1
... = opScalar SrcScalar1
=>
SrcScalar1 = copy SrcVector1
... = opVector SrcVector1<kill>
This is obviously wrong. The proper update consists in:
1. Propagate the kill status from the copy to the new opVector
2. Reset the kill status on the copy, since the live-range of
SrcVector1 got extended.
This fixes some of the machine verifier errors for AArch64 with make check.
llvm-svn: 267180
|
| |
|
|
| |
llvm-svn: 267178
|
| |
|
|
|
|
|
|
|
| |
Summary: eq imply [u|s]ge and [u|s]le are true.
Remove redundant logic by implementing isImpliedFalseByMatchingCmp(Pred1, Pred2)
as isImpliedTrueByMatchingCmp(Pred1, getInversePredicate(Pred2)).
llvm-svn: 267177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(... while still not using a PostDomTree)
The way we use isKnownNotFullPoison from SCEV today, the new CFG walking
logic will not trigger for any realistic cases -- it will kick in only
for situations where we could have merged the contiguous basic blocks
anyway[0], since the poison generating instruction dominates all of its
non-PHI uses (which are the only uses we consider right now).
However, having this change in place will allow a later bugfix to break
fewer llvm-lit tests.
[0]: i.e. cases where block A branches to block B and B is A's only
successor and A is B's only predecessor.
Reviewers: broune, bjarke.roune
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19212
llvm-svn: 267175
|
| |
|
|
| |
llvm-svn: 267173
|
| |
|
|
|
|
|
|
|
| |
Summary: [u|s]gt and [u|s]lt imply [u|s]ge and [u|s]le are true, respectively.
I've simplified the existing tests and added additional tests to cover the new
cases mentioned above. I've also added tests for all the cases where the
first compare doesn't imply anything about the second compare.
llvm-svn: 267171
|
| |
|
|
|
|
|
|
|
|
|
| |
- Switch few loops to range-based for loops
- Fix nop insertion at the end of BB
- Fix formatting
- Check for endpgm
Differential Revision: http://reviews.llvm.org/D19380
llvm-svn: 267167
|
| |
|
|
|
|
| |
Commit r266861 was the reason for failing tests in LLVM test suite.
llvm-svn: 267166
|
| |
|
|
| |
llvm-svn: 267165
|
| |
|
|
|
|
| |
Also add tests for other instructions from HexagonSystemInst.td.
llvm-svn: 267162
|
| |
|
|
| |
llvm-svn: 267160
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CachingMemorySSAWalker::invalidateInfo was using IsCall to determine
which cache map needed to be cleared of entries referring to the invalidated
MemoryAccess, but there could also be entries referring to it in the
other cache map (value entries, not key entries). This change just
clears both tables to be conservatively correct.
Also add a verifyRemoved() function, called when expensive
checks (i.e. XDEBUG) are enabled to verify that the invalidated
MemoryAccess object is not referenced in any of the caches.
Reviewers: dberlin, george.burgess.iv
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19388
llvm-svn: 267157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This new pass allows targets to use the hazard recognizer without having
to also run one of the schedulers. This is useful when compiling with
optimizations disabled for targets that still need noop hazards
to be handled correctly.
Reviewers: hfinkel, atrick
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18594
llvm-svn: 267156
|
| |
|
|
|
|
|
|
| |
We take the intersection of overflow flags while CSE'ing.
This permits us to consider two instructions with different overflow
behavior to be replaceable.
llvm-svn: 267153
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When generating assembly using -m16 we must explicitly mark it as
16-bit. Emit .code16 at beginning of file. Fixes wrong results when
using -fno-integrated-as.
Reviewers: dwmw2
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19392
llvm-svn: 267152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When targetting MIPS64R6 some of the patterns for select were guarded by a
broken predicate. The predicate was supposed to test if a constant value
could fit in a 16 bit zero-extended field. Instead the value was tested to
fit in a 16 bit sign-extended field. For negative constants of native word
width this resulted in wrong code generation.
Reviewers: vkalintiris, dsanders
Differential Review: http://reviews.llvm.org/D19378
llvm-svn: 267151
|
| |
|
|
| |
llvm-svn: 267149
|
| |
|
|
|
|
| |
r267049 broke multiple buildbots (e.g. clang-cmake-mips, and clang-x86_64-linux-selfhost-modules) which the follow-ups have not yet resolved and this is preventing subsequent committers from being notified about additional failures on the affected buildbots.
llvm-svn: 267148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When optimizing PHIs which have inputs floating point binary
operators, we preserve all IR flags except the fast math
flags.
This change removes the logic which tracked some of the IR flags
(no wrap, exact) and replaces it by doing an and on the IR flags of
all inputs to the PHI - which will also handle the fast math
flags.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19370
llvm-svn: 267139
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19354
llvm-svn: 267137
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15026
llvm-svn: 267130
|
| |
|
|
| |
llvm-svn: 267128
|
| |
|
|
|
|
| |
It introduced buildbot failures on clang-cmake-mips, clang-ppc64le-linux, among others.
llvm-svn: 267127
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
rL256194 transforms truncations between vectors of integers into PACKUS/PACKSS
operations during DAG combine. This generates better code for truncate, so cost
of truncate needs to be changed but looks like it got changed only in SSE2 table
Whereas this change is also applicable for SSE4.1, so the cost of truncate needs
to be changed for that as well. Cost of “TRUNCATE v16i32 to v16i8” & “TRUNCATE
v16i16 to v16i8” should be same in SSE4.1 & SSE2 table. Removing their cost from
SSE4.1, so it will fall back to SSE2.
Reviewers: Simon Pilgrim
llvm-svn: 267123
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
take the address of a global object:
void func1() {
...
}
int main(int argc, char** argv) {
void (*pFunc)();
pFunc = &func1
pFunc();
...
}
Phabricator review: http://reviews.llvm.org/D19368
llvm-svn: 267120
|
| |
|
|
|
|
|
|
| |
This reverts commit r267022, due to an ASan failure:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549
llvm-svn: 267115
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18687
llvm-svn: 267114
|
| |
|
|
|
|
|
| |
We assumed that flags were only present on binary operators. This is
not true, they may also be present on calls and fcmps.
llvm-svn: 267113
|
| |
|
|
| |
llvm-svn: 267112
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
EarlyCSE had inconsistent behavior with regards to flag'd instructions:
- In some cases, it would pessimize if the available instruction had
different flags by not performing CSE.
- In other cases, it would miscompile if it replaced an instruction
which had no flags with an instruction which has flags.
Fix this by being more consistent with our flag handling by utilizing
andIRFlags.
llvm-svn: 267111
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also adds a small comment blurb on control flow + no-wrap flags, since
that question came up a few days back on llvm-dev.
Reviewers: bjarke.roune, broune
Subscribers: sanjoy, mcrosier, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D19209
llvm-svn: 267110
|
| |
|
|
|
|
| |
since the custom logic just did what Expand does when CTTZ/CTLZ are Legal. NFC
llvm-svn: 267109
|
| |
|
|
|
|
| |
they will be converted to CTLZ/CTTZ by LegalizeDAG. Remove extra instructions that only existed to to contain patterns that match the zero_undef operations. NFC
llvm-svn: 267108
|
| |
|
|
| |
llvm-svn: 267107
|
| |
|
|
|
|
|
| |
InlineAsm instead of a Module (NFC)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267106
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267105
|
| |
|
|
|
|
|
|
| |
(I have no idea why is it needed)
Fixup for r267103
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267104
|
| |
|
|
|
|
|
|
|
| |
parse inline assembly (NFC)
I plan to call this from ThinLTOCodeGenerator.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267103
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This intrinsic returns true if the current thread belongs to a live pixel
and false if it belongs to a pixel that we are executing only for derivative
computation. It will be used by Mesa to implement gl_HelperInvocation.
Note that for pixels that are killed during the shader, this implementation
also returns true, but it doesn't matter because those pixels are always
disabled in the EXEC mask.
This unearthed a corner case in the instruction verifier, which complained
about a v_cndmask 0, 1, exec, exec<imp-use> instruction. That's stupid but
correct code, so make the verifier accept it as such.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19191
llvm-svn: 267102
|