| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
warning.
llvm-svn: 180700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjCARCContract instead of ObjCARCOpts.
Turning retains into retainRV calls disrupts the data flow analysis in
ObjCARCOpts. Thus we move it as late as we can by moving it into
ObjCARCContract.
We leave in the conversion from retainRV -> retain in ObjCARCOpt since
it enables the dataflow analysis.
rdar://10813093
llvm-svn: 180698
|
| |
|
|
|
|
| |
optimization.
llvm-svn: 180697
|
| |
|
|
| |
llvm-svn: 180696
|
| |
|
|
| |
llvm-svn: 180694
|
| |
|
|
|
|
| |
ConnectTDBUTraversals so that I can prevent Changed = true from being set. This prevents an infinite loop.
llvm-svn: 180693
|
| |
|
|
|
|
| |
in the string table for static linking
llvm-svn: 180692
|
| |
|
|
|
|
| |
in the string table for static linking
llvm-svn: 180691
|
| |
|
|
|
|
| |
functionality change)
llvm-svn: 180690
|
| |
|
|
| |
llvm-svn: 180688
|
| |
|
|
|
|
| |
delete blank.
llvm-svn: 180687
|
| |
|
|
| |
llvm-svn: 180686
|
| |
|
|
| |
llvm-svn: 180685
|
| |
|
|
| |
llvm-svn: 180684
|
| |
|
|
| |
llvm-svn: 180683
|
| |
|
|
|
|
| |
Patch by Robert Wilhelm.
llvm-svn: 180682
|
| |
|
|
| |
llvm-svn: 180680
|
| |
|
|
| |
llvm-svn: 180679
|
| |
|
|
| |
llvm-svn: 180678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem this patch addresses is the handling of register tie
constraints in AsmMatcherEmitter, where one operand is tied to a
sub-operand of another operand. The typical scenario for this to
happen is the tie between the "write-back" register of a pre-inc
instruction, and the base register sub-operand of the memory address
operand of that instruction.
The current AsmMatcherEmitter code attempts to handle tied
operands by emitting the operand as usual first, and emitting
a CVT_Tied node when handling the second (tied) operand. However,
this really only works correctly if the tied operand does not
have sub-operands (and isn't a sub-operand itself). Under those
circumstances, a wrong MC operand list is generated.
In discussions with Jim Grosbach, it turned out that the MC operand
list really ought not to contain tied operands in the first place;
instead, it ought to consist of exactly those operands that are
named in the AsmString. However, getting there requires significant
rework of (some) targets.
This patch fixes the immediate problem, and at the same time makes
one (small) step in the direction of the long-term solution, by
implementing two changes:
1. Restricts the AsmMatcherEmitter handling of tied operands to
apply solely to simple operands (not complex operands or
sub-operand of such).
This means that at least we don't get silently corrupt MC operand
lists as output. However, if we do have tied sub-operands, they
would now no longer be handled at all, except for:
2. If we have an operand that does not occur in the AsmString,
and also isn't handled as tied operand, simply emit a dummy
MC operand (constant 0).
This works as long as target code never attempts to access
MC operands that do no not occur in the AsmString (and are
not tied simple operands), which happens to be the case for
all targets where this situation can occur (ARM and PowerPC).
[ Note that this change means that many of the ARM custom
converters are now superfluous, since the implement the
same "hack" now performed already by common code. ]
Longer term, we ought to fix targets to never access *any*
MC operand that does not occur in the AsmString (including
tied simple operands), and then finally completely remove
all such operands from the MC operand list.
Patch approved by Jim Grosbach.
llvm-svn: 180677
|
| |
|
|
|
|
|
|
|
|
| |
When Reassociator optimize "(x | C1)" ^ "(X & C2)", it may swap the two
subexpressions, however, it forgot to swap cached constants (of C1 and C2)
accordingly.
rdar://13739160
llvm-svn: 180676
|
| |
|
|
|
|
| |
Patch by Dimitry Andric.
llvm-svn: 180675
|
| |
|
|
|
|
| |
Patch by Dimitry Andric
llvm-svn: 180674
|
| |
|
|
| |
llvm-svn: 180673
|
| |
|
|
| |
llvm-svn: 180672
|
| |
|
|
|
|
|
|
| |
The CodeGen aspects of this test are already covered by cfi-frame.ll;
making it an assembly file reduces the risk of incidental changes
affecting the test.
llvm-svn: 180671
|
| |
|
|
| |
llvm-svn: 180670
|
| |
|
|
|
|
|
| |
The existing code also failed to allocate a buffer for it so getcwd corrupted
the stack. sys::fs::current_path takes care of the memory management.
llvm-svn: 180669
|
| |
|
|
|
|
|
|
|
| |
Mainly adding paranoid checks for the closing brace of a function to
help with FileCheck error readability. Also some other minor changes.
No actual CHECK changes.
llvm-svn: 180668
|
| |
|
|
|
|
|
| |
Naturally, we should be able to pass in extra instructions, not just
extra blocks.
llvm-svn: 180667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to me an obvious place to allow target passes to annotate
memory operations. There are plenty of bits, and I'm not aware of
another good way for early target passes to propagate hints along to
later passes. Target independent transforms can simply preserve them,
the way they preserve the other flags. Like MachineMemOperands in
general, if the target flags are lost we must still generate correct
code.
This has lots of uses, but I want this flexibility now to make it
easier to work with the new MachineTraceMetrics
analysis. MachineTraceMetrics can gather a lot of information about
instructions based on the surrounding code. This information can be
used to influence postRA machine passes that don't work on SSA form.
llvm-svn: 180666
|
| |
|
|
| |
llvm-svn: 180665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mostly related to management of the stack frame
for the interpreter.
- First, if the expression can be interpreted,
allocate the stack frame in the target process
(to make sure pointers are valid) but only
read/write to the copy in the host's memory.
- Second, keep the memory allocations for the
stack frame and the materialized struct as
member variables of ClangUserExpression. This
avoids memory allocations and deallocations
each time the expression runs.
<rdar://problem/13043685>
llvm-svn: 180664
|
| |
|
|
|
|
|
|
| |
null pointer.
<rdar://problem/13745684>
llvm-svn: 180663
|
| |
|
|
|
|
| |
access to 'z' where 'z' was not in scope.
llvm-svn: 180662
|
| |
|
|
|
|
|
|
|
|
|
| |
make the gdb tests and the Windows bots happy.
The Path::GetCurrentDirectory API is not equivalent to ::getcwd(), so
r180652 causes a gdb tests to fail. On the other hand, <sys/param.h>
isn't defined on Windows systems, so that causes Windows builds to fail.
rdar://12237559
llvm-svn: 180661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to determine whether or not we're on a darwin platform for debug code
emitting.
Solves the problem of a module with no triple on the command line
and no triple in the module using non-gdb ok features on darwin. Fix
up the member-pointers test to check the correct things for cross
platform (DW_FORM_flag is a good prefix).
Unfortunately no testcase because I have no ideas how to test something
without a triple and without a triple in the module yet check
precisely on two platforms. Ideas welcome.
llvm-svn: 180660
|
| |
|
|
| |
llvm-svn: 180659
|
| |
|
|
| |
llvm-svn: 180658
|
| |
|
|
|
|
|
| |
This fixes pr15763.
Patch by David Fang.
llvm-svn: 180657
|
| |
|
|
| |
llvm-svn: 180656
|
| |
|
|
|
|
| |
Synthetic children provider for NSOrderedSet
llvm-svn: 180655
|
| |
|
|
|
|
|
|
| |
We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (name, parent node).
TypeIsImmutable is added to TBAAStructTag node.
llvm-svn: 180654
|
| |
|
|
|
|
|
| |
We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (name, parent node).
llvm-svn: 180653
|
| |
|
|
|
|
|
| |
bots recover.
rdar://12237559
llvm-svn: 180652
|
| |
|
|
| |
llvm-svn: 180651
|
| |
|
|
|
|
|
| |
and limit comment extraction to public c++
bases. // rdar://13647476
llvm-svn: 180646
|
| |
|
|
|
|
|
|
| |
presence of malformed class types.
<rdar://problem/13740646>
llvm-svn: 180645
|
| |
|
|
|
|
|
|
|
| |
structs are compatible, check whether the fields
of the structs have the same name. This prevents
erroneous coalescing of (in particular) anonymous
structs.
llvm-svn: 180644
|
| |
|
|
|
|
|
|
| |
module file where a module object came from.
rdar://13743084
llvm-svn: 180643
|