| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 140260
|
| |
|
|
| |
llvm-svn: 140258
|
| |
|
|
| |
llvm-svn: 140257
|
| |
|
|
|
|
| |
should be initialized to UnknownABI.
llvm-svn: 140254
|
| |
|
|
|
|
|
| |
Vector SetCC result types need to be type-legalized.
This code worked before because scalar result types are known to be legal.
llvm-svn: 140249
|
| |
|
|
|
|
| |
comes to replace the problematic check that was removed in r139995.
llvm-svn: 140246
|
| |
|
|
| |
llvm-svn: 140237
|
| |
|
|
| |
llvm-svn: 140235
|
| |
|
|
|
|
|
|
|
|
|
|
| |
assert(!"error message");
To:
assert(0 && "error message");
which is more consistant across the code base.
llvm-svn: 140234
|
| |
|
|
| |
llvm-svn: 140233
|
| |
|
|
|
|
| |
Check if architecture & ABI combination is valid.
llvm-svn: 140230
|
| |
|
|
| |
llvm-svn: 140229
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is still a hack until we can teach tblgen to generate the
optional CPSR operand rather than an implicit CPSR def. But the
strangeness is now limited to the selection DAG. ADD/SUB MI's no
longer have implicit CPSR defs, nor do we allow flag setting variants
of these opcodes in machine code. There are several corner cases to
consider, and getting one wrong would previously lead to nasty
miscompilation. It's not the first time I've debugged one, so this
time I added enough verification to ensure it won't happen again.
llvm-svn: 140228
|
| |
|
|
| |
llvm-svn: 140227
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MachO-only at the moment, sorry.
Usage:
$ llvm-objdump -d -m -g -dsym=a.out.dSYM/Contents/Resources/DWARF/a.out a.out
_main:
100000e90: 55 pushq %rbp ## test.c:11:3
…
llvm-svn: 140224
|
| |
|
|
| |
llvm-svn: 140223
|
| |
|
|
|
|
| |
script. Only the testsuite project needs to know this information.
llvm-svn: 140220
|
| |
|
|
|
|
| |
that the disassembler outputs annotations on with the streamer that the InstPrinter will print them on.
llvm-svn: 140217
|
| |
|
|
|
|
| |
here anymore and has been migrated to the test-suite project.
llvm-svn: 140216
|
| |
|
|
| |
llvm-svn: 140214
|
| |
|
|
| |
llvm-svn: 140213
|
| |
|
|
|
|
|
|
| |
SCCPSolver::ResolvedUndefsIn. If we do, we can end up in a situation where a function is resolved to return a constant, but the caller is marked overdefined, which confuses the code later.
<rdar://problem/9956541> (again).
llvm-svn: 140210
|
| |
|
|
|
|
|
| |
subvector inserts and extracts. Initial patch by Rackover, Zvi with
some tweak done by me.
llvm-svn: 140204
|
| |
|
|
| |
llvm-svn: 140203
|
| |
|
|
|
|
|
|
| |
It happens (for example) when you want to have a dependency on the .so
with the specific version, like liblzma.so.1.0.0 or
libcrypto.so.0.9.8.
llvm-svn: 140201
|
| |
|
|
| |
llvm-svn: 140199
|
| |
|
|
|
|
|
| |
Though I think it may be obsolete with the loop extract changes. And I couldn't
get the old version of LLVM to compile so that I could reduce this testcase.
llvm-svn: 140197
|
| |
|
|
|
|
|
| |
Some passes require breaking critical edges before they're called. Don't
segfault because of that.
llvm-svn: 140196
|
| |
|
|
|
|
| |
paths through the if-then-else.
llvm-svn: 140195
|
| |
|
|
| |
llvm-svn: 140194
|
| |
|
|
|
|
|
|
|
| |
The landing pad must accompany the invoke when it's extracted. However, if it
does, then the loop isn't properly extracted. I.e., the resulting extraction has
a loop in it. The extracted function is then extracted, etc. resulting in an
infinite loop.
llvm-svn: 140193
|
| |
|
|
|
|
|
|
|
| |
This was only needed to locate llvm-gcc's installation directory when clang
falls back to run llvm-gcc for i386 kexts. As of clang svn r140187, we're
now just searching paths with several different Darwin versions on either
side of the current version, so this is no longer needed.
llvm-svn: 140188
|
| |
|
|
| |
llvm-svn: 140186
|
| |
|
|
|
|
|
| |
This fixes PR10963. Thanks to Benjamin for finding the wrong tablegen
declaration.
llvm-svn: 140184
|
| |
|
|
| |
llvm-svn: 140183
|
| |
|
|
|
|
| |
does not support Thumb2 dsp instructions. rdar://10152911.
llvm-svn: 140181
|
| |
|
|
| |
llvm-svn: 140178
|
| |
|
|
| |
llvm-svn: 140177
|
| |
|
|
| |
llvm-svn: 140176
|
| |
|
|
|
|
|
|
|
|
| |
extract its associated landing pad block as well. However, that landing pad
block may have more than one predecessor. So split the landing pad block so that
individual landing pads have only one predecessor.
This type of transformation may produce a false positive with bugpoint.
llvm-svn: 140173
|
| |
|
|
| |
llvm-svn: 140172
|
| |
|
|
| |
llvm-svn: 140169
|
| |
|
|
|
|
| |
blocks to extract.
llvm-svn: 140168
|
| |
|
|
|
|
| |
complete length.
llvm-svn: 140167
|
| |
|
|
| |
llvm-svn: 140166
|
| |
|
|
| |
llvm-svn: 140164
|
| |
|
|
| |
llvm-svn: 140163
|
| |
|
|
|
|
|
|
|
|
| |
No functionality change. The hook makes it explicit which patterns
require "special" handling. i.e. it self-documents tblgen
deficiencies. I plan to add verification in ExpandISelPseudos and
Thumb2SizeReduce to catch any missing hasPostISelHooks. Otherwise it's
too fragile.
llvm-svn: 140160
|
| |
|
|
| |
llvm-svn: 140158
|
| |
|
|
| |
llvm-svn: 140157
|