| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
individual operands instead of taking a temporary array
llvm-svn: 86619
|
|
|
|
|
|
| |
value.
llvm-svn: 86618
|
|
|
|
|
|
| |
ApplyHeaderSearchOptions now.
llvm-svn: 86617
|
|
|
|
| |
llvm-svn: 86616
|
|
|
|
| |
llvm-svn: 86614
|
|
|
|
|
|
|
|
| |
takes decimated instructions and applies identities to them. This
is pretty minimal at this point, but I plan to pull some instcombine
logic out into these and similar routines.
llvm-svn: 86613
|
|
|
|
|
|
| |
CompilerInvocation.
llvm-svn: 86612
|
|
|
|
| |
llvm-svn: 86611
|
|
|
|
| |
llvm-svn: 86610
|
|
|
|
|
|
| |
only construct a single LangInfo). This matches how it is used in practice (since the compiler only it invokes it for one file at a time).
llvm-svn: 86609
|
|
|
|
| |
llvm-svn: 86608
|
|
|
|
| |
llvm-svn: 86607
|
|
|
|
| |
llvm-svn: 86606
|
|
|
|
| |
llvm-svn: 86604
|
|
|
|
|
|
|
| |
simplifies instruction users of PHIs when the phi is eliminated. This
will be moved to transforms/utils after some other refactoring.
llvm-svn: 86603
|
|
|
|
| |
llvm-svn: 86602
|
|
|
|
| |
llvm-svn: 86601
|
|
|
|
| |
llvm-svn: 86600
|
|
|
|
| |
llvm-svn: 86599
|
|
|
|
| |
llvm-svn: 86598
|
|
|
|
|
|
|
| |
warning, to match gcc. It used to be warning, so
better keep it a warning (it broke a certain project).
llvm-svn: 86597
|
|
|
|
|
|
|
| |
ArrayType>()) does not instantiate. Update all callers that used this
unsafe feature to use the appropriate ASTContext::getAs*ArrayType method.
llvm-svn: 86596
|
|
|
|
| |
llvm-svn: 86595
|
|
|
|
| |
llvm-svn: 86592
|
|
|
|
|
|
|
| |
when looking for a name within a given DeclContext. Now enumerators
will show up in code-completion results.
llvm-svn: 86591
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was generated. This caused code like this:
## The asm code for the function
.section __TEXT,__const
.align 2
lJTI11_0:
LJTI11_0:
.long LBB11_16
.long LBB11_4
.long LBB11_5
.long LBB11_6
.long LBB11_7
.long LBB11_8
.long LBB11_9
.long LBB11_10
.long LBB11_11
.long LBB11_12
.long LBB11_13
.long LBB11_14
Leh_func_end11: ## <---now in the wrong section!
The `Leh_func_end11' would then end up in the wrong section, causing the
resulting EH frame information to be wrong:
__ZL11CheckRightsjPKcbRbRP6NSData.eh:
.set Lset500eh,Leh_frame_end11-Leh_frame_begin11
.long Lset500eh ; Length of Frame Information Entry
Leh_frame_begin11:
.long Leh_frame_begin11-Leh_frame_common
.long Leh_func_begin11-.
.set Lset501eh,Leh_func_end11-Leh_func_begin11
.long Lset501eh ; FDE address range
`Lset501eh' is now something huge instead of the real value.
The X86 back-end generates the jump table after the EH information is
emitted. Do the same here.
llvm-svn: 86588
|
|
|
|
|
|
| |
its element type. Fixes pr5432.
llvm-svn: 86587
|
|
|
|
|
|
| |
the compiler, and start flood filling it into clang-cc.
llvm-svn: 86586
|
|
|
|
| |
llvm-svn: 86585
|
|
|
|
| |
llvm-svn: 86584
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions. This makes CodeGen dumps significantly less noisy.
Example before:
BL <ga:@bar>, %R0<imp-def>, %R1<imp-def,dead>, %R2<imp-def,dead>, %R3<imp-def,dead>, %R12<imp-def,dead>, %LR<imp-def,dead>, %D0<imp-def,dead>, %D1<imp-def,dead>, %D2<imp-def,dead>, %D3<imp-def,dead>, %D4<imp-def,dead>, %D5<imp-def,dead>, %D6<imp-def,dead>, %D7<imp-def,dead>, %D16<imp-def,dead>, %D17<imp-def,dead>, %D18<imp-def,dead>, %D19<imp-def,dead>, %D20<imp-def,dead>, %D21<imp-def,dead>, %D22<imp-def,dead>, %D23<imp-def,dead>, %D24<imp-def,dead>, %D25<imp-def,dead>, %D26<imp-def,dead>, %D27<imp-def,dead>, %D28<imp-def,dead>, %D29<imp-def,dead>, %D30<imp-def,dead>, %D31<imp-def,dead>, %CPSR<imp-def,dead>, %FPSCR<imp-def,dead>
Same example after:
BL <ga:@bar>, %R0<imp-def>, %R1<imp-def,dead>, %LR<imp-def,dead>, %CPSR<imp-def,dead>, ...
llvm-svn: 86583
|
|
|
|
|
|
| |
GVN to be more aggressive. Patch by Hans Wennborg! (with a comment added by me)
llvm-svn: 86582
|
|
|
|
|
|
| |
overloaded operator().
llvm-svn: 86581
|
|
|
|
|
|
| |
dependencies were overly conservative for memory access that are known not to alias.
llvm-svn: 86580
|
|
|
|
|
|
|
| |
declaration invalid if the constructor can't be properly built. Addresses
remaining review comments from Fariborz for r86500.
llvm-svn: 86579
|
|
|
|
|
|
|
|
|
| |
templates. The instantiation of these default arguments must be (and
now, is) delayed until the template argument is actually used, at
which point we substitute all levels of template arguments
concurrently.
llvm-svn: 86578
|
|
|
|
| |
llvm-svn: 86577
|
|
|
|
|
|
| |
static array types. Thanks to Duncan for pointing this out!
llvm-svn: 86576
|
|
|
|
| |
llvm-svn: 86575
|
|
|
|
| |
llvm-svn: 86574
|
|
|
|
| |
llvm-svn: 86573
|
|
|
|
|
|
| |
paragraph to be more precise.
llvm-svn: 86572
|
|
|
|
|
|
|
|
| |
unless we start implementing command-line switches which override the default
calling convention, so the effect is mostly to silence unknown attribute
warnings.)
llvm-svn: 86571
|
|
|
|
|
|
| |
nested templates, for my own sanity's sake
llvm-svn: 86570
|
|
|
|
|
|
|
|
|
|
|
|
| |
the loop. This is needed because with indirectbr it may not be possible
for LoopSimplify to guarantee that all loop exit predecessors are
inside the loop. This fixes PR5437.
LCCSA no longer actually requires LoopSimplify form, but for now it
must still have the dependency because the PassManager doesn't know
how to schedule LoopSimplify otherwise.
llvm-svn: 86569
|
|
|
|
|
|
|
|
| |
- free(NULL) is a nop anyway.
- if someone thinks calling clang_disposeString twice should be legal
please change the method to take a pointer.
llvm-svn: 86568
|
|
|
|
| |
llvm-svn: 86567
|
|
|
|
|
|
| |
argument
llvm-svn: 86566
|
|
|
|
| |
llvm-svn: 86565
|
|
|
|
| |
llvm-svn: 86564
|