| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for the lldb team so most of but not all of the values are
to be printed as hex with this option. Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.
There may be some tweaks need to places that may still be in
decimal that they want in hex. Specially for arm. I made my best
guess. Any tweaks from here should be simple.
I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes. But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.
rdar://8109283
llvm-svn: 169393
|
| |
|
|
|
|
|
|
|
| |
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs
reviewed by Evan Cheng <evan.cheng@apple.com>
llvm-svn: 169391
|
| |
|
|
| |
llvm-svn: 169383
|
| |
|
|
|
|
| |
This mirrors the change in ASan & TSan done in r168864.
llvm-svn: 169378
|
| |
|
|
|
|
|
| |
LinkOnceODRLinkage globals may be removed in GlobalOpt if not used in the
current module.
llvm-svn: 169377
|
| |
|
|
|
|
| |
Generate VPBLENDD for AVX2 and VPBLENDW for v16i16 type on AVX2.
llvm-svn: 169366
|
| |
|
|
| |
llvm-svn: 169359
|
| |
|
|
| |
llvm-svn: 169344
|
| |
|
|
|
|
|
|
|
| |
x ^ -1.
Patch by David Majnemer.
rdar://12755626
llvm-svn: 169339
|
| |
|
|
|
|
| |
(TIL that Clang's -Wparentheses ignores 'x || y && "foo"' on purpose. Neat.)
llvm-svn: 169337
|
| |
|
|
|
|
|
| |
class of attributes. This makes it much easier to check for errors and to reuse
the code.
llvm-svn: 169336
|
| |
|
|
|
|
| |
runtime. If we cant prove statically that the pointers are disjoint then we add the runtime check.
llvm-svn: 169334
|
| |
|
|
| |
llvm-svn: 169331
|
| |
|
|
| |
llvm-svn: 169325
|
| |
|
|
|
|
|
| |
reduction variable is not used outside the loop then we ran into an
endless loop. This change checks if we found the original PHI.
llvm-svn: 169324
|
| |
|
|
|
|
|
| |
Allow the central functions to be inlined, and use the argumentless
isHint() function when possible.
llvm-svn: 169319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change attempts to simplify (X^Y) -> X or Y in the user's context if we know that
only bits from X or Y are demanded.
A minimized case is provided bellow. This change will simplify "t>>16" into "var1 >>16".
=============================================================
unsigned foo (unsigned val1, unsigned val2) {
unsigned t = val1 ^ 1234;
return (t >> 16) | t; // NOTE: t is used more than once.
}
=============================================================
Note that if the "t" were used only once, the expression would be finally optimized as well.
However, with with this change, the optimization will take place earlier.
Reviewed by Nadav, Thanks a lot!
llvm-svn: 169317
|
| |
|
|
| |
llvm-svn: 169315
|
| |
|
|
|
|
| |
using multiclass.
llvm-svn: 169314
|
| |
|
|
|
|
|
|
|
| |
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
llvm-svn: 169312
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies the fix for PR13303 now with more justification. Based on my
execution of the GDB 7.5 test suite this results in:
expected passes: 16101 -> 20890 (+30%)
unexpected failures: 4826 -> 637 (-77%)
There are 23 checks that used to pass and now fail. They are all in
gdb.reverse. Investigating a few looks like they were accidentally passing
due to extra breakpoints being set by this bug. They're generally due to the
difference in end location between gcc and clang, the test suite is trying to
set breakpoints on the closing '}' that clang doesn't associate with any
instructions.
llvm-svn: 169304
|
| |
|
|
|
|
|
|
|
| |
textually as NativeClient. Also added a link to the native client project for
readers unfamiliar with it.
A Clang patch will follow shortly.
llvm-svn: 169291
|
| |
|
|
| |
llvm-svn: 169288
|
| |
|
|
|
|
|
|
| |
trailing/leading zeros)
instructions.
llvm-svn: 169287
|
| |
|
|
| |
llvm-svn: 169284
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on 64-bit PowerPC ELF.
The patch includes code to handle external assembly and MC output with the
integrated assembler. It intentionally does not support the "old" JIT.
For the initial-exec TLS model, the ABI requires the following to calculate
the address of external thread-local variable x:
Code sequence Relocation Symbol
ld 9,x@got@tprel(2) R_PPC64_GOT_TPREL16_DS x
add 9,9,x@tls R_PPC64_TLS x
The register 9 is arbitrary here. The linker will replace x@got@tprel
with the offset relative to the thread pointer to the generated GOT
entry for symbol x. It will replace x@tls with the thread-pointer
register (13).
The two test cases verify correct assembly output and relocation output
as just described.
PowerPC-specific selection node variants are added for the two
instructions above: LD_GOT_TPREL and ADD_TLS. These are inserted
when an initial-exec global variable is encountered by
PPCTargetLowering::LowerGlobalTLSAddress(), and later lowered to
machine instructions LDgotTPREL and ADD8TLS. LDgotTPREL is a pseudo
that uses the same LDrs support added for medium code model's LDtocL,
with a different relocation type.
The rest of the processing is straightforward.
llvm-svn: 169281
|
| |
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
| |
|
|
|
|
| |
executed due to CF.
llvm-svn: 169223
|
| |
|
|
|
|
|
| |
This comment has the dual effect of blocking reorderings with the
sort_include script.
llvm-svn: 169221
|
| |
|
|
|
|
|
|
|
| |
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
llvm-svn: 169218
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the code that actually performs the if-conversion during vectorization.
We can now vectorize this code:
for (int i=0; i<n; ++i) {
unsigned k = 0;
if (a[i] > b[i]) <------ IF inside the loop.
k = k * 5 + 3;
a[i] = k; <---- K is a phi node that becomes vector-select.
}
llvm-svn: 169217
|
| |
|
|
|
|
| |
does not change the current behavior)
llvm-svn: 169216
|
| |
|
|
| |
llvm-svn: 169214
|
| |
|
|
| |
llvm-svn: 169213
|
| |
|
|
| |
llvm-svn: 169212
|
| |
|
|
|
|
|
| |
The type of shirt-right (logical or arithemetic) should remain unchanged
when transforming "X << C1 >> C2" into "X << (C1-C2)"
llvm-svn: 169209
|
| |
|
|
|
|
| |
emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.
llvm-svn: 169200
|
| |
|
|
| |
llvm-svn: 169198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the alignment is clamped to TargetFrameLowering.getStackAlignment if the target
does not support stack realignment or the option "realign-stack" is off.
This will cause miscompile if the address is treated as aligned and add is
replaced with or in DAGCombine.
Added a bool StackRealignable to TargetFrameLowering to check whether stack
realignment is implemented for the target. Also added a bool RealignOption
to MachineFrameInfo to check whether the option "realign-stack" is on.
rdar://12713765
llvm-svn: 169197
|
| |
|
|
| |
llvm-svn: 169196
|
| |
|
|
| |
llvm-svn: 169195
|
| |
|
|
| |
llvm-svn: 169194
|
| |
|
|
|
|
|
| |
These functions have been replaced by TRI::getRegAllocationHints() which
provides the same capabilities.
llvm-svn: 169192
|
| |
|
|
|
|
|
| |
Now that there can be multiple hint registers from targets, it doesn't
make sense to have a function that returns 'the' preferred register.
llvm-svn: 169190
|
| |
|
|
|
|
|
|
|
| |
Targets can provide multiple hints now, so getRegAllocPref() doesn't
make sense any longer because it only returns one preferred register.
Replace it with getSimpleHint() in the remaining heuristics. This
function only
llvm-svn: 169188
|
| |
|
|
|
|
|
|
|
| |
No functional change for this commit. The follow-up patch will add more stuff to
these functions.
rdar://12713765
llvm-svn: 169186
|
| |
|
|
| |
llvm-svn: 169183
|
| |
|
|
|
|
|
|
|
|
|
| |
This change tries to simmplify E1 = " X >> C1 << C2" into :
- E2 = "X << (C2 - C1)" if C2 > C1, or
- E2 = "X >> (C1 - C2)" if C1 > C2, or
- E2 = X if C1 == C2.
Reviewed by Nadav. Thanks!
llvm-svn: 169182
|
| |
|
|
|
|
|
|
| |
Virtual registers with a known preferred register are prioritized by
RAGreedy. This function makes the condition explicit without depending
on getRegAllocPref().
llvm-svn: 169179
|
| |
|
|
|
|
|
|
|
| |
This small change adds support for that. It will make all MCJIT tests pass
in make-check on BigEndian platforms.
Patch by Petar Jovanovic.
llvm-svn: 169178
|