| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 236260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operands of a commuted instruction.
Revision 220239 exposed a latent bug in method
'TargetInstrInfo::commuteInstruction'. When commuting the operands of a machine
instruction, method 'commuteInstruction' didn't correctly propagate the
'IsUndef' flag to the register operands of the new (commuted) instruction.
Before this patch, the following instruction:
%vreg4<def> = VADDSDrr %vreg14, %vreg5<undef>; FR64:%vreg4,%vreg14,%vreg5
was wrongly converted by method 'commuteInstruction' into:
%vreg4<def> = VADDSDrr %vreg5, %vreg14<undef>; FR64:%vreg4,%vreg5,%vreg14
The correct instruction should have been:
%vreg4<def> = VADDSDrr %vreg5<undef>, %vreg14; FR64:%vreg4,%vreg5,%vreg14
This patch fixes the problem in method 'TargetInstrInfo::commuteInstruction'.
When swapping the operands of a machine instruction, we now make sure that
'IsUndef' flags are correctly set.
Added test case 'pr23103.ll'.
Differential Revision: http://reviews.llvm.org/D9406
llvm-svn: 236258
|
| |
|
|
|
|
| |
Add string to the section header string table as we add sections.
llvm-svn: 236257
|
| |
|
|
|
|
|
| |
This avoids passing it around and lets us build a small helper to add
a section to the table.
llvm-svn: 236255
|
| |
|
|
| |
llvm-svn: 236253
|
| |
|
|
| |
llvm-svn: 236250
|
| |
|
|
|
|
|
|
| |
If you somehow added a MachineOperand to an instruction
that did not have the parent set, the verifier would
crash since it attempts to use the operand's parent.
llvm-svn: 236249
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the test case here, the 'unreachable' BB was removed by BranchFolding because its empty.
It then rewrote the jump from 'entry' to jump to its fallthrough, which was a landing pad.
This results in 'entry' jumping to 2 different landing pads, which fails the machine verifier.
rdar://problem/20750162
llvm-svn: 236248
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
temporary.
Because of that:
1. The machine verifier was complaining on such code.
2. The generate code worked just because the thumb reduction size pass fixed the
opcode.
rdar://problem/20749824
llvm-svn: 236247
|
| |
|
|
|
|
|
|
|
| |
Unlike 32-bit ARM, AArch64 can use wzr/xzr to implement this without the need
for a separate instruction.
rdar://18679590
llvm-svn: 236245
|
| |
|
|
|
|
|
| |
Use them in WinEHPrepare so that we can spot any toolchain bugs that
come up.
llvm-svn: 236244
|
| |
|
|
|
|
|
|
|
| |
changes:
Don't apply on hexagon and NVPTX since they no longer claim to support UADDO/USUBO
Add location to getConstant
Drop comment about the ops being turned into expand
llvm-svn: 236240
|
| |
|
|
|
|
|
|
|
|
|
| |
During ELF writing, there is no need to further relax the sections, so we
should not be creating fragments. This patch avoids doing so in all cases
but debug section compression (that is next).
Also, the ELF format is fairly simple to write. We can do a single pass over
the sections to write them out and compute the section header table.
llvm-svn: 236235
|
| |
|
|
|
|
| |
warning; NFC.
llvm-svn: 236234
|
| |
|
|
| |
llvm-svn: 236213
|
| |
|
|
| |
llvm-svn: 236212
|
| |
|
|
|
|
|
|
|
| |
and AVX-512 instruction selection patterns.
All other patches, including tests will follow.
http://reviews.llvm.org/D7665
llvm-svn: 236211
|
| |
|
|
|
|
| |
Sign extension of i8 to i16 was placing the unpacked bytes in the lower byte instead of the upper byte.
llvm-svn: 236209
|
| |
|
|
|
|
| |
end of previous line. NFC
llvm-svn: 236206
|
| |
|
|
| |
llvm-svn: 236205
|
| |
|
|
|
|
| |
Fold an assignment into an if. Use auto on the result of a couple dyn_casts. NFC
llvm-svn: 236204
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Optimizing these well are especially interesting for IRCE since it
"clamps" values by generating this sort of pattern through SCEV
expressions.
Depends on D9352.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9353
llvm-svn: 236203
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After this change `MatchSelectPattern` recognizes the following form
of SMIN:
Y >s C ? ~Y : ~C == ~Y <s ~C ? ~Y : ~C = SMIN(~Y, ~C)
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9352
llvm-svn: 236202
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bug found with AFL fuzz.
Reviewers: rafael, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9361
llvm-svn: 236200
|
| |
|
|
|
|
|
|
|
|
|
|
| |
At the least it should be guarded by some kind of target hook.
It also introduced catastrophic compile time and code quality
regressions on some out of tree targets (test case still being
reduced/sanitized).
Sanjay agreed with reverting this patch until these issues can be
resolved.
llvm-svn: 236199
|
| |
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 236193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will cause hot nodes to appear closer to the root.
The literature says building the tree like this makes it a near-optimal (in
terms of search time given key frequencies) binary search tree. In LLVM's case,
we can do up to 3 comparisons in each leaf node, so it might be better to opt
for lower tree height in some cases; that's something to look into in the
future.
Differential Revision: http://reviews.llvm.org/D9318
llvm-svn: 236192
|
| |
|
|
|
|
|
|
| |
Make it an error instead.
Bug found with AFL fuzz.
llvm-svn: 236190
|
| |
|
|
|
|
| |
Saves finding the MCSectionData just to do a map lookup.
llvm-svn: 236189
|
| |
|
|
| |
llvm-svn: 236187
|
| |
|
|
|
|
|
|
|
|
| |
This was breaking sqlite with the machine verifier because operand 0 was a def according to tablegen, but didn't have the 'isDef' flag set.
Looking at the ISA, its clear that this operand is a source as writing to st(0) is implicit. So move the operand to the correct place in the td file.
rdar://problem/20751584
llvm-svn: 236183
|
| |
|
|
| |
llvm-svn: 236175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit x86 MSVC-style exceptions are functionaly similar to 64-bit, but
they take no arguments. Instead, they implicitly use the value of EBP
passed in by the caller as a pointer to the parent's frame. In LLVM, we
can represent this as llvm.frameaddress(1), and feed that into all of
our calls to llvm.framerecover.
The next steps are:
- Add an alloca to the fs:00 linked list of handlers
- Add something like llvm.sjlj.lsda or generalize it to store in the
alloca
- Move state number calculation to WinEHPrepare, arrange for
FunctionLoweringInfo to call it
- Use the state numbers to insert explicit loads and stores in the IR
llvm-svn: 236172
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move the fold introduced in r236031:
http://reviews.llvm.org/rL236031
to its own helper function, so we can use it for other binops.
This is a preliminary step before partially solving:
https://llvm.org/bugs/show_bug.cgi?id=21768
https://llvm.org/bugs/show_bug.cgi?id=23116
llvm-svn: 236171
|
| |
|
|
| |
llvm-svn: 236166
|
| |
|
|
| |
llvm-svn: 236163
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
decomposing it into pointee type + address space
Many of the callers already have the pointer type anyway, and for the
couple of callers that don't it's pretty easy to call PointerType::get
on the pointee type and address space.
This avoids LLParser from using PointerType::getElementType when parsing
GlobalAliases from IR.
llvm-svn: 236160
|
| |
|
|
| |
llvm-svn: 236158
|
| |
|
|
|
|
| |
There is no need to first accumulate it in fragments.
llvm-svn: 236157
|
| |
|
|
| |
llvm-svn: 236156
|
| |
|
|
|
|
|
| |
This avoids having to compute the number upfront, which will be used in the
next patch.
llvm-svn: 236153
|
| |
|
|
| |
llvm-svn: 236150
|
| |
|
|
|
|
| |
There is no need to accumulate it in fragments first.
llvm-svn: 236148
|
| |
|
|
| |
llvm-svn: 236147
|
| |
|
|
|
|
|
|
| |
Mostly copy-and-paste from Sparc v8 architecture.
Differential Revision: http://reviews.llvm.org/D8741
llvm-svn: 236146
|
| |
|
|
|
|
|
|
|
|
| |
Instead of accumulating the content in a fragment first, just write it
to the output stream.
Also put it first in the section table, so that we never have to worry
about its index being >= SHN_LORESERVE.
llvm-svn: 236145
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 236143
|
| |
|
|
| |
llvm-svn: 236141
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There's probably no way to test BXJ, but if the compiler ever did emit it
during CodeGen it would have to be a block terminator so "isBranch" is
appropriate.
BLX is more tricky. Clearly a call, but it affects surprisingly little.
rdar://18719544
llvm-svn: 236140
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9263
llvm-svn: 236139
|