| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
and u/srem.
llvm-svn: 164614
|
|
|
|
| |
llvm-svn: 164611
|
|
|
|
|
|
|
|
| |
to chains or cycles between PHIs and/or selects. Also add a couple of
really nice test cases reduced from Kostya's reports in PR13905 and
PR13906. Both are fixed by this patch.
llvm-svn: 164596
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was only be able to detect problems if the pointer was a numerical
value (eg inttoptr i32 1 to i32*), but not if it was an alloca or globa. The
reason was the use of ComputeMaskedBits: imagine you have "alloca i8, align 2",
and ask ComputeMaskedBits what it knows about the bits of the alloca pointer.
It can tell you that the bottom bit is known zero (due to align 2) but it can't
tell you that bit 1 is known one. That's because the address could be an even
multiple of 2 rather than an odd multiple, eg it might be a multiple of 4. Thus
trying to use KnownOne is ineffective in the case of an alloca as it will never
have any bits set. Instead look explicitly for constant offsets from allocas
and globals.
llvm-svn: 164595
|
|
|
|
|
|
| |
caller returns x86_fp80 via st0. rdar://12229511
llvm-svn: 164588
|
|
|
|
| |
llvm-svn: 164587
|
|
|
|
|
|
|
|
|
|
| |
David (I think), but I would appreciate folks verifying that this fixes
the big crasher.
I'm still working on a reduced test case, but because this was causing
problems I wanted to get the fix checked in quickly.
llvm-svn: 164585
|
|
|
|
|
|
| |
it's not a dead store if that pointer is used. Whoops!
llvm-svn: 164583
|
|
|
|
|
|
| |
ensure that the code was generated properly. Future work would be finding some way to test the actual result that would be computed.
llvm-svn: 164582
|
|
|
|
|
|
| |
rdar://9795790
llvm-svn: 164577
|
|
|
|
|
|
|
| |
declaration to use the same form as in the rest of the file. No functionality
change.
llvm-svn: 164576
|
|
|
|
|
|
|
|
|
| |
Even out-of-line jump tables can be in the code section, so mark them
as data-regions for those targets which support the directives.
rdar://12362871&12362974
llvm-svn: 164571
|
|
|
|
| |
llvm-svn: 164570
|
|
|
|
|
|
| |
Also remove an unused argument.
llvm-svn: 164567
|
|
|
|
|
|
|
|
|
| |
I also moved the SDKROOT setting into the make flags, since clearing it from
the environment isn't good enough to override a setting on the make command
line. That hasn't been a problem but it could be, and it's good to be
consistent with the way UNIVERSAL_SDK_PATH is handled.
llvm-svn: 164565
|
|
|
|
|
|
| |
dead.
llvm-svn: 164561
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 164560
|
|
|
|
|
|
|
| |
store when handling byval arguments. Thus preventing reordering of the store
with load with post-RA scheduler.
llvm-svn: 164553
|
|
|
|
| |
llvm-svn: 164548
|
|
|
|
| |
llvm-svn: 164540
|
|
|
|
|
|
| |
This avoids a crash in visitAllocaInst when target data isn't available.
llvm-svn: 164539
|
|
|
|
|
|
| |
Queue the fallout. ;]
llvm-svn: 164480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer promotion analogous to vector promotion. When there is an
integer alloca being accessed both as its integer type and as a narrower
integer type, promote the narrower access to "insert" and "extract" the
smaller integer from the larger one, and make the integer alloca
a candidate for promotion.
In the new formulation, we don't care about target legal integer or use
thresholds to control things. Instead, we only perform this promotion to
an integer type which the frontend has already emitted a load or store
for. This bounds the scope and prevents optimization passes from
coalescing larger and larger entities into a single integer.
llvm-svn: 164479
|
|
|
|
|
|
| |
Patch by Kai!
llvm-svn: 164476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
across the uses of the alloca. It's entirely possible for negative
numbers to come up here, and in some rare cases simply doing the 2's
complement arithmetic isn't the correct decision. Notably, we can't zext
the index of the GEP. The definition of GEP is that these offsets are
sign extended or truncated to the size of the pointer, and then wrapping
2's complement arithmetic used.
This patch fixes an issue that comes up with *no* input from the
buildbots or bootstrap afaict. The only place where it manifested,
disturbingly, is Clang's own regression test suite. A reduced and
targeted collection of tests are added to cope with this. Note that I've
tried to pin down the potential cases of overflow, but may have missed
some cases. I've tried to add a few cases to test this, but its hard
because LLVM has quite limited support for >64bit constructs.
llvm-svn: 164475
|
|
|
|
| |
llvm-svn: 164474
|
|
|
|
| |
llvm-svn: 164472
|
|
|
|
| |
llvm-svn: 164471
|
|
|
|
| |
llvm-svn: 164465
|
|
|
|
| |
llvm-svn: 164459
|
|
|
|
| |
llvm-svn: 164458
|
|
|
|
|
|
|
|
|
| |
As before with load instructions, oddities like "asr #32", "rrx" could
be printed incorrectly.
Patch by Chris Lidbury.
llvm-svn: 164456
|
|
|
|
|
|
|
|
|
| |
This patch fixes load/store instructions to handle less common cases
like "asr #32", "rrx" properly throughout the MC layer.
Patch by Chris Lidbury.
llvm-svn: 164455
|
|
|
|
| |
llvm-svn: 164453
|
|
|
|
| |
llvm-svn: 164452
|
|
|
|
|
|
|
| |
Allow subtargets to tie SchedReadWrite types to processor specific
sequences or variants.
llvm-svn: 164451
|
|
|
|
|
|
| |
Used by clang to print parameter indexes.
llvm-svn: 164440
|
|
|
|
|
|
|
|
| |
This silences several analyzer warnings within LLVM, and provides a slightly
nicer crash experience when someone calls isa<>, cast<>, or dyn_cast<> with
a null pointer.
llvm-svn: 164439
|
|
|
|
|
|
|
| |
This silences literally dozens of analyzer warnings on LLVM (since DenseMap
is such a commonly-used class).
llvm-svn: 164438
|
|
|
|
| |
llvm-svn: 164435
|
|
|
|
| |
llvm-svn: 164434
|
|
|
|
|
|
| |
TargetLowering's callback functions.
llvm-svn: 164431
|
|
|
|
| |
llvm-svn: 164430
|
|
|
|
| |
llvm-svn: 164429
|
|
|
|
| |
llvm-svn: 164428
|
|
|
|
|
|
|
|
|
|
|
| |
selects with a constant condition. This resulted in the operands
remaining live through the SROA rewriter. Most of the time, this just
caused some dead allocas to persist and get zapped by later passes, but
in one case found by Joerg, it caused a crash when we tried to *promote*
the alloca despite it having this dead use. We already have the
mechanisms in place to handle this, just wire select up to them.
llvm-svn: 164427
|
|
|
|
|
|
|
|
|
| |
whether or not we want to print out backtrace information. Useful
for libraries that don't need backtrace information on a crash.
rdar://11844710
llvm-svn: 164426
|
|
|
|
| |
llvm-svn: 164425
|
|
|
|
| |
llvm-svn: 164424
|
|
|
|
| |
llvm-svn: 164420
|