| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
Apparently we never added code to expand these pseudo instructions, and in
over a year, no one has noticed. Our register allocator must be awesome!
llvm-svn: 137551
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This caused a race condition where a thread calls ~LLVMContextImpl which calls
Module::dropAllReferences which calls begin() on an empty ilist that would
create the sentinel, which racily accesses the global context.
This can not be fixed by locking inside createSentinel because the lock would
need to be shared with all users of the global context, including those that
reside outside LLVM's own code.
llvm-svn: 137546
|
| |
|
|
|
|
|
|
|
|
| |
of the instruction.
Note that this change affects the existing non-atomic load and store
instructions; the parser now accepts both forms, and the change is noted
in the release notes.
llvm-svn: 137527
|
| |
|
|
|
|
|
|
|
| |
Tidy up the code a bit and push the definition of the value next to the uses
to try to minimize this sort of issue from arising again while I'm at it.
rdar://9945172
llvm-svn: 137525
|
| |
|
|
| |
llvm-svn: 137521
|
| |
|
|
|
|
|
|
| |
vectors. It operates on 128-bit elements instead of regular scalar
types. Recognize shuffles that are suitable for VPERM2F128 and teach
the x86 legalizer how to handle them.
llvm-svn: 137519
|
| |
|
|
| |
llvm-svn: 137518
|
| |
|
|
| |
llvm-svn: 137515
|
| |
|
|
|
|
| |
Partial fix for rdar://9945172.
llvm-svn: 137513
|
| |
|
|
|
|
| |
they're the correct type.
llvm-svn: 137511
|
| |
|
|
|
|
| |
add another batch of tests.
llvm-svn: 137502
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implements the 'landingpad' instruction. It's used to indicate that a basic
block is a landing pad. There are several restrictions on its use (see
LangRef.html for more detail). These restrictions allow the exception handling
code to gather the information it needs in a much more sane way.
This patch has the definition, implementation, C interface, parsing, and bitcode
support in it.
llvm-svn: 137501
|
| |
|
|
| |
llvm-svn: 137499
|
| |
|
|
|
|
| |
from certain USAT16 encodings.
llvm-svn: 137494
|
| |
|
|
| |
llvm-svn: 137487
|
| |
|
|
| |
llvm-svn: 137485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer register to a floating point register. It is not valid to interpret
the value of a floating pointer register as part of a double precision
floating point value after a single precision floating point computational
or move instruction stores its result to the register.
- In the test case, the following code is generated before this patch is
applied:
mtc1 $zero, $f2 ; unformatted copy to $f2
mov.s $f0, $f2 ; $f0 is in single format
sdc1 $f12, 0($sp)
mov.s $f1, $f2 ; $f1 is in single format
c.eq.d $f12, $f0 ; $f0 cannot be interpreted as double
- The following code is generated after this patch is applied:
mtc1 $zero, $f0 ; unformatted copy to $f0
mtc1 $zero, $f1 ; unformatted copy to $f1
c.eq.d $f12, $f0 ; $f0 can be interpreted as double
Bhanu Chetlapalli and Chris Dearman at MIPS technologies reported this bug and
provided the test case.
llvm-svn: 137484
|
| |
|
|
| |
llvm-svn: 137483
|
| |
|
|
| |
llvm-svn: 137482
|
| |
|
|
| |
llvm-svn: 137481
|
| |
|
|
| |
llvm-svn: 137480
|
| |
|
|
| |
llvm-svn: 137479
|
| |
|
|
| |
llvm-svn: 137478
|
| |
|
|
| |
llvm-svn: 137476
|
| |
|
|
| |
llvm-svn: 137470
|
| |
|
|
| |
llvm-svn: 137468
|
| |
|
|
| |
llvm-svn: 137466
|
| |
|
|
| |
llvm-svn: 137463
|
| |
|
|
|
|
| |
when building with assertions disabled.
llvm-svn: 137460
|
| |
|
|
|
|
| |
instead. This matches what as does.
llvm-svn: 137414
|
| |
|
|
|
|
| |
Fix by Ivan Baev. Sorry I don't have a unit test, but the fix is obvious so I don't want to delay it.
llvm-svn: 137404
|
| |
|
|
|
|
| |
is returned through a bitcast.
llvm-svn: 137402
|
| |
|
|
|
|
|
|
|
| |
the retains and releases all use the same SSA pointer value.
Also, don't let CFG hazards disrupt nested retain+release pair
optimizations.
llvm-svn: 137399
|
| |
|
|
|
|
|
| |
rather than plain postorder, so that CFG constructs like single-exit loops
are reliably visited in a sensible order.
llvm-svn: 137398
|
| |
|
|
|
|
|
| |
This is possible now that we now longer provide an interface to iterate
the interference overlaps.
llvm-svn: 137397
|
| |
|
|
| |
llvm-svn: 137389
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
SCEV unrolling can unroll loops with arbitrary induction variables. It
is a prerequisite for -disable-iv-rewrite performance. It is also
easily handles loops of arbitrary structure including multiple exits
and is generally more robust.
This is under a temporary option to avoid affecting default
behavior for the next couple of weeks. It is needed so that I can
checkin unit tests for updateUnloop.
llvm-svn: 137384
|
| |
|
|
| |
llvm-svn: 137381
|
| |
|
|
|
|
|
|
| |
The Query class now holds two iterators instead of an InterferenceResult
instance. The iterators are used as bookmarks for repeated
collectInterferingVRegs calls.
llvm-svn: 137380
|
| |
|
|
|
|
| |
warning.
llvm-svn: 137378
|
| |
|
|
| |
llvm-svn: 137375
|
| |
|
|
| |
llvm-svn: 137372
|
| |
|
|
| |
llvm-svn: 137371
|
| |
|
|
| |
llvm-svn: 137370
|
| |
|
|
| |
llvm-svn: 137368
|
| |
|
|
| |
llvm-svn: 137367
|
| |
|
|
| |
llvm-svn: 137364
|
| |
|
|
| |
llvm-svn: 137363
|
| |
|
|
|
|
|
| |
inserts and extracts. This simple combine makes us generate only 1
instruction instead of 11 in the v8 case.
llvm-svn: 137362
|
| |
|
|
| |
llvm-svn: 137359
|