| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
for the analyzer.
This setting still isn't enabled yet in the analyzer. This is
just prep work.
llvm-svn: 178317
|
| |
|
|
|
|
|
|
|
| |
Mips assembler supports macros that allows the OR instruction
to have an immediate parameter. This patch adds an instruction
alias that converts this macro into a Mips ORI instruction.
Contributer: Vladimir Medic
llvm-svn: 178316
|
| |
|
|
|
|
|
|
|
|
| |
PC relative loads are missing disassembly comments when disassembled in a live process.
This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.
The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.
llvm-svn: 178315
|
| |
|
|
| |
llvm-svn: 178314
|
| |
|
|
|
|
|
|
| |
'isa' ivar is accessed provided it is the first
ivar. Fixit hint will follow in another patch.
This is continuation of // rdar://13503456
llvm-svn: 178313
|
| |
|
|
|
|
|
|
|
| |
- RDRAND always clears the destination value when a random value is not
available (i.e. CF == 0). This value is truncated or zero-extended as
the false boolean value to be returned. Boolean simplification needs
to skip this 'zext' or 'trunc' node.
llvm-svn: 178312
|
| |
|
|
| |
llvm-svn: 178311
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
“newed” pointers to escape
Add a new callback that notifies checkers when a const pointer escapes. Currently, this only works
for const pointers passed as a top level parameter into a function. We need to differentiate the const
pointers escape from regular escape since the content pointed by const pointer will not change;
if it’s a file handle, a file cannot be closed; but delete is allowed on const pointers.
This should suppress several false positives reported by the NewDelete checker on llvm codebase.
llvm-svn: 178310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
participates in the computation of the nil we warn about.
We should only suppress a bug report if the IDCed or null returned nil value is directly related to the value we are warning about. This was
not the case for nil receivers - we would suppress a bug report that had an IDCed nil receiver on the path regardless of how it’s
related to the warning.
1) Thread EnableNullFPSuppression parameter through the visitors to differentiate between tracking the value which
is directly responsible for the bug and other values that visitors are tracking (ex: general tracking of nil receivers).
2) in trackNullOrUndef specifically address the case when a value of the message send is nil due to the receiver being nil.
llvm-svn: 178309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
indirect call.
To enable a load of a call address to be folded with that call, this
load is moved from outside of callseq into callseq. Such a moving
adds a non-glued node (that load) into a glued sequence. This non-glue
load is only removed when DAG selection folds them into a memory form
call instruction. When such instruction selection is disabled, it breaks
DAG schedule.
To prevent that, such moving is disabled when target favors register
indirect call.
Previous workaround disabling CALL32m/CALL64m insn selection is removed.
llvm-svn: 178308
|
| |
|
|
|
|
|
| |
This covers a few cases where the class of a member pointer is not a
CXXRecordDecl.
llvm-svn: 178307
|
| |
|
|
|
|
| |
through the ARC Dataflow analysis. By the time we get to the ARC dataflow analysis, any objc_retainBlock calls are not optimizable.
llvm-svn: 178306
|
| |
|
|
|
|
|
|
|
|
|
| |
immediate in a register. I don't believe this should ever fail, but I see no
harm in trying to make this code bullet proof.
I've added an assert to ensure my assumtion is correct. If the assertion fires
something is wrong and we should fix it, rather then just silently fall back to
SelectionDAG isel.
llvm-svn: 178305
|
| |
|
|
|
|
|
|
|
|
|
| |
Mips assembler allows following to be used as aliased instructions:
jal $rs for jalr $rs
jal $rd,$rd for jalr $rd,$rs
This patch provides alias definitions in td files and test cases to show the usage.
Contributer: Vladimir Medic
llvm-svn: 178304
|
| |
|
|
| |
llvm-svn: 178303
|
| |
|
|
|
|
| |
Go ahead and use the full path for both the .gcno and .gcda files.
llvm-svn: 178302
|
| |
|
|
| |
llvm-svn: 178301
|
| |
|
|
| |
llvm-svn: 178300
|
| |
|
|
| |
llvm-svn: 178299
|
| |
|
|
| |
llvm-svn: 178298
|
| |
|
|
|
|
|
| |
I'm not 100% sure what should happen here to find the real
CXXRecordDecl.
llvm-svn: 178297
|
| |
|
|
| |
llvm-svn: 178296
|
| |
|
|
|
|
| |
char[]
llvm-svn: 178295
|
| |
|
|
|
|
|
| |
To do this, thread DiagnosticErrorTrap's hasUnrecoverableErrorOccurred through
to Scope.
llvm-svn: 178294
|
| |
|
|
| |
llvm-svn: 178293
|
| |
|
|
|
|
|
| |
By default, omit the children for a char[] and just show the string contents
Can be overridden by appropriate command-line flags
llvm-svn: 178292
|
| |
|
|
| |
llvm-svn: 178291
|
| |
|
|
| |
llvm-svn: 178290
|
| |
|
|
|
|
|
| |
Wouldn't it be cool if we had a compiler for Windows that could warn
about these things?
llvm-svn: 178289
|
| |
|
|
|
|
| |
anything more they would like to see on it, please let me know. Debug mode is activated by compiling with -D_LIBCPP_DEBUG2=1. Eventually _LIBCPP_DEBUG2 will be renamed to just _LIBCPP_DEBUG.
llvm-svn: 178288
|
| |
|
|
|
|
| |
Otherwise, the CHECK-NOT's might trigger depending on the host's CPU.
llvm-svn: 178287
|
| |
|
|
|
|
|
|
| |
Compiling in 32-bit mode on a P7 would assert after 64-bit DAG combines were
added for bswap with load/store. This is because these combines are really only
valid in 64-bit mode, regardless of the CPU (and this was not being checked).
llvm-svn: 178286
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since we handle optimizable objc_retainBlocks through strength reduction
in OptimizableIndividualCalls, we know that all code after that point
will only see non-optimizable objc_retainBlock calls. IsForwarding is
only called by functions after that point, so it is ok to just classify
objc_retainBlock as non-forwarding.
<rdar://problem/13249661>.
llvm-svn: 178285
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
objc_retainBlock is optimizable.
If an objc_retainBlock has the copy_on_escape metadata attached to it
AND if the block pointer argument only escapes down the stack, we are
allowed to strength reduce the objc_retainBlock to to an objc_retain and
thus optimize it.
Current there is logic in the ARC data flow analysis to handle
this case which is complicated and involved making distinctions in
between objc_retainBlock and objc_retain in certain places and
considering them the same in others.
This patch simplifies said code by:
1. Performing the strength reduction in the initial ARC peephole
analysis (ObjCARCOpts::OptimizeIndividualCalls).
2. Changes the ARC dataflow analysis (which runs after the peephole
analysis) to consider all objc_retainBlock calls to not be optimizable
(since if the call was optimizable, we would have strength reduced it
already).
This patch leaves in the infrastructure in the ARC dataflow analysis to
handle this case, which due to 2 will just be dead code. I am doing this
on purpose to separate the removal of the old code from the testing of
the new code.
<rdar://problem/13249661>.
llvm-svn: 178284
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This also relaxes the requirement on Windows that the member pointer
class type be a complete type (http://llvm.org/PR12070). We still ask
for a complete type to instantiate any templates (MSVC does this), but
if that fails we continue as normal, relying on any inheritance
attributes on the declaration.
Reviewers: rjmccall
CC: triton, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D568
llvm-svn: 178283
|
| |
|
|
|
|
|
|
| |
is accessed via accessing 'isa' ivar to use
object_getClass/object_setClass apis.
// rdar://13503456
llvm-svn: 178282
|
| |
|
|
| |
llvm-svn: 178281
|
| |
|
|
|
|
| |
Thanks to Bill Schmidt for pointing this out!
llvm-svn: 178280
|
| |
|
|
| |
llvm-svn: 178279
|
| |
|
|
| |
llvm-svn: 178278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
|
| |
|
|
|
|
|
|
| |
These are 64-bit load/store with byte-swap, and available on the P7 and the A2.
Like the similar instructions for 16- and 32-bit words, these are matched in the
target DAG-combine phase against load/store-bswap pairs.
llvm-svn: 178276
|
| |
|
|
|
|
|
|
| |
the upper bit is set.
They should always be zero-extended, not sign extended. Added test case.
llvm-svn: 178275
|
| |
|
|
|
|
|
|
|
| |
The suggestion was already in the text of the note; this just adds the
actual fixit and the appropriate test cases.
Patch by Alexander Zinenko!
llvm-svn: 178274
|
| |
|
|
|
|
|
|
|
|
|
| |
likely be implicitly truncated:
* All forms of Bitwise-and, bitwise-or, and integer multiplication.
* The assignment form of integer addition, subtraction, and exclusive-or
* The RHS of the comma operator
* The LHS of left shifts.
llvm-svn: 178273
|
| |
|
|
|
|
|
| |
This is about the GNU Binutils' assembler and linker, so reflect that in the
name.
llvm-svn: 178272
|
| |
|
|
|
|
|
|
| |
The concept of such a software distribution is not tied to the Linux kernel;
for example Debian GNU/Linux, Debian GNU/Hurd, and Debian GNU/kFreeBSD all
share the same source packages and generally the same user-space configuration.
llvm-svn: 178270
|
| |
|
|
| |
llvm-svn: 178269
|
| |
|
|
| |
llvm-svn: 178268
|
| |
|
|
| |
llvm-svn: 178267
|