| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction lower optimization" in the pre-RA scheduler.
The optimization, rather the hack, was done before MI use-list was available.
Now we should be able to implement it in a better way, perhaps in the
two-address pass until a MI scheduler is available.
Now that the scheduler has to backtrack to handle call sequences. Adding
artificial scheduling constraints is just not safe. Furthermore, the hack
is not taking all the other scheduling decisions into consideration so it's just
as likely to pessimize code. So I view disabling this optimization goodness
regardless of PR11314.
llvm-svn: 144267
|
| |
|
|
|
|
|
|
| |
Note: These patterns only works in some cases because
many times the load sd node is bitcasted from a load
node of a different type.
llvm-svn: 144266
|
| |
|
|
|
|
|
| |
literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.
llvm-svn: 144265
|
| |
|
|
| |
llvm-svn: 144264
|
| |
|
|
|
|
|
| |
but it is sometimes useful to track blocks. Do so. Also
optimize the storage of these expressions.
llvm-svn: 144263
|
| |
|
|
|
|
| |
things out correctly again.
llvm-svn: 144261
|
| |
|
|
|
|
|
| |
is currently too inefficient to allow us to use it for array initializers, but
fortunately we usually don't yet need to evaluate such initializers.
llvm-svn: 144260
|
| |
|
|
|
|
|
|
| |
Fixed an issue where if you had an initialized global variable, we would not
link it up correctly in the debug info if the .o file had the symbols as
UNDF + EXT (undefined external). We now properly link the globals.
llvm-svn: 144259
|
| |
|
|
|
|
|
| |
determine if the value is negative and flip the sign accordingly.
rdar://10422026
llvm-svn: 144258
|
| |
|
|
| |
llvm-svn: 144257
|
| |
|
|
|
|
|
| |
modules first in the target, then fall back to the global shared module
cache, then fall back to the global module list.
llvm-svn: 144256
|
| |
|
|
|
|
| |
options to llvm-build, so the all-targets etc. components are defined properly.
llvm-svn: 144255
|
| |
|
|
|
|
| |
internal breakpoints can be negative, and anyway it is a good idea to use break_id_t for breakpoints, no?)
llvm-svn: 144254
|
| |
|
|
|
|
|
|
|
|
| |
handle defining the "magic" target related components (like native,
nativecodegen, and engine).
- We still require these components to be in the project (currently in
lib/Target) so that we have a place to document them and hopefully make it
more obvious that they are "magic".
llvm-svn: 144253
|
| |
|
|
| |
llvm-svn: 144252
|
| |
|
|
|
|
|
|
|
| |
change the generated library .a file name once we fully switch over, but
simplifies how we treat these targets without requiring more special casing
(since their library group name and the codegen library name currently map to
the same "llvm-config" style component name).
llvm-svn: 144251
|
| |
|
|
|
|
| |
- Gives us a place to hang target specific metadata (like whether the target has a JIT).
llvm-svn: 144250
|
| |
|
|
| |
llvm-svn: 144249
|
| |
|
|
|
|
| |
"TypedefContext". No functionality change.
llvm-svn: 144248
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The TII.foldMemoryOperand hook preserves implicit operands from the
original instruction. This is not what we want when those implicit
operands refer to the register being spilled.
Implicit operands referring to other registers are preserved.
This fixes PR11347.
llvm-svn: 144247
|
| |
|
|
|
|
|
|
| |
*mmintrin.h to take them into account.
<rdar://problem/10341145>
llvm-svn: 144246
|
| |
|
|
| |
llvm-svn: 144245
|
| |
|
|
| |
llvm-svn: 144244
|
| |
|
|
| |
llvm-svn: 144243
|
| |
|
|
|
|
| |
rdar://10422955
llvm-svn: 144242
|
| |
|
|
| |
llvm-svn: 144241
|
| |
|
|
|
|
|
| |
Fixed an issue with the gdb format stuff for any aliases that expand to
contain a "--".
llvm-svn: 144240
|
| |
|
|
|
|
|
|
|
|
|
| |
store is dead.
Currently checks alignment and killing stores on a power of 2 boundary as this is likely
to trim the size of the earlier store without breaking large vector stores into scalar ones.
Fixes <rdar://problem/10140300>
llvm-svn: 144239
|
| |
|
|
| |
llvm-svn: 144237
|
| |
|
|
| |
llvm-svn: 144236
|
| |
|
|
| |
llvm-svn: 144233
|
| |
|
|
| |
llvm-svn: 144232
|
| |
|
|
|
|
|
| |
The SCEVAffFunc is now only used to express memory accesses. Give it a proper
name and rework the class such that this is obvious.
llvm-svn: 144231
|
| |
|
|
|
|
|
| |
This also removes the construction of MayAliasSets that became invalid when
removing the use of SCEVAffFunc.
llvm-svn: 144230
|
| |
|
|
|
|
|
| |
We do not use it anymore. It was replaced by SCEVVisitors like the
SCEVValidator.
llvm-svn: 144229
|
| |
|
|
|
|
|
| |
This check was necessary because of the use AffineSCEVIterator in TempScopInfo.
As we removed this use recently it is not necessary any more.
llvm-svn: 144228
|
| |
|
|
| |
llvm-svn: 144227
|
| |
|
|
| |
llvm-svn: 144226
|
| |
|
|
| |
llvm-svn: 144224
|
| |
|
|
| |
llvm-svn: 144223
|
| |
|
|
| |
llvm-svn: 144222
|
| |
|
|
| |
llvm-svn: 144221
|
| |
|
|
| |
llvm-svn: 144220
|
| |
|
|
|
|
| |
issue from PR11319.
llvm-svn: 144216
|
| |
|
|
|
|
| |
rdar://10418009
llvm-svn: 144213
|
| |
|
|
| |
llvm-svn: 144212
|
| |
|
|
| |
llvm-svn: 144211
|
| |
|
|
| |
llvm-svn: 144210
|
| |
|
|
| |
llvm-svn: 144209
|
| |
|
|
| |
llvm-svn: 144204
|