| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 149881
|
| |
|
|
|
|
| |
before inserting into the vector. Fixes PR11930.
llvm-svn: 149855
|
| |
|
|
| |
llvm-svn: 149801
|
| |
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
| |
|
|
| |
llvm-svn: 149798
|
| |
|
|
|
|
|
|
| |
We had been generating load/store instructions with the default alignment
for the vector element type, even when the pointer argument had less alignment.
<rdar://problem/10538555>
llvm-svn: 149794
|
| |
|
|
|
|
|
|
|
| |
of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
llvm-svn: 149781
|
| |
|
|
| |
llvm-svn: 149734
|
| |
|
|
|
|
|
|
|
| |
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
llvm-svn: 149679
|
| |
|
|
| |
llvm-svn: 149638
|
| |
|
|
|
|
|
|
|
|
| |
attribute into CodeGenModule::SetLLVMFunctionAttributesForDefinition().
Previously it resided in CodeGenModule::GetOrCreateLLVMFunction, which
for some reason wasn't called for ObjC class methods, see
http://code.google.com/p/address-sanitizer/issues/detail?id=33
llvm-svn: 149605
|
| |
|
|
|
|
|
|
|
| |
a full type go ahead and emit it if we currently only have a forward
declaration.
Fixes gdb bots for gdb1090.exp and call-ar-st.exp.
llvm-svn: 149560
|
| |
|
|
| |
llvm-svn: 149544
|
| |
|
|
| |
llvm-svn: 149543
|
| |
|
|
| |
llvm-svn: 149531
|
| |
|
|
|
|
| |
Spotted by rjmcall.
llvm-svn: 149526
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.
What was done:
1. Changed semantics of index inside the getCaseValue method:
getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.
Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
llvm-svn: 149482
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.
Original log:
ConstantArray::get() (for strings) is going away, use
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
llvm-svn: 149477
|
| |
|
|
|
|
| |
instead of the entire class definition.
llvm-svn: 149474
|
| |
|
|
|
|
| |
Patch by Niels Grewe!
llvm-svn: 149401
|
| |
|
|
| |
llvm-svn: 149377
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
llvm-svn: 149363
|
| |
|
|
|
|
| |
as well as ConstantArray.
llvm-svn: 149347
|
| |
|
|
|
|
|
| |
argument. twik to support the test case.
// rdar://10444476
llvm-svn: 149298
|
| |
|
|
|
|
|
|
|
| |
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
In this patch, the null path releases consumed argument.
// rdar://10444474
llvm-svn: 149279
|
| |
|
|
| |
llvm-svn: 149237
|
| |
|
|
|
|
| |
are now in IntrinsicsX86.td.
llvm-svn: 149235
|
| |
|
|
|
|
| |
connecting intrinsics and builtins in IntrinsicsX86.td.
llvm-svn: 149233
|
| |
|
|
|
|
|
| |
recently. This also conveniently gets clang ready for a change about to
land in mainline.
llvm-svn: 149225
|
| |
|
|
| |
llvm-svn: 149205
|
| |
|
|
|
|
|
|
| |
kill the retain from the return site.
This has the workaround nature. It's badness all around.
llvm-svn: 149193
|
| |
|
|
|
|
|
| |
in the presence of straight-line cleanups. This is a simple but
important case, particularly for ARC.
llvm-svn: 149190
|
| |
|
|
|
|
|
|
| |
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474
llvm-svn: 149184
|
| |
|
|
|
|
|
|
|
| |
There is really no reason to have these only available on x86. It's
just __builtin_c[tl]z for shorts.
Modernize the test while at it.
llvm-svn: 149183
|
| |
|
|
| |
llvm-svn: 149104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM supports clz and ctz directly and both operations have well-defined
results for zero. There is no disadvantage in performance to using the
defined-at-zero versions of llvm.ctlz/cttz intrinsics. We're running into
ARM-specific code written with the assumption that __builtin_clz(0) == 32,
even though that value is technically undefined. The code is failing now
because of llvm optimizations that are taking advantage of the undef
behavior (specifically svn r147255). There's nothing wrong with that
optimization on x86 where any incorrect assumptions about __builtin_clz(0)
will quickly be exposed. For ARM, though, optimizations based on that undef
behavior are likely to cause subtle bugs. Other targets with defined-at-zero
clz/ctz support may want to override the default behavior as well.
llvm-svn: 149086
|
| |
|
|
| |
llvm-svn: 149051
|
| |
|
|
|
|
|
|
|
| |
the gdb testsuite complains too much about the ordering of items printed,
even if the offsets in the debug info are correct.
This reverts commit 027cb30af828f07750f9185782822297a5c57231.
llvm-svn: 149049
|
| |
|
|
| |
llvm-svn: 149047
|
| |
|
|
|
|
|
| |
around, in the process cleaning up the various gcc/msvc compiler
workarounds.
llvm-svn: 149036
|
| |
|
|
| |
llvm-svn: 149015
|
| |
|
|
| |
llvm-svn: 149013
|
| |
|
|
| |
llvm-svn: 149012
|
| |
|
|
|
|
| |
MSVC-compatible way. Patch by Joe Groff.
llvm-svn: 148992
|
| |
|
|
| |
llvm-svn: 148982
|
| |
|
|
| |
llvm-svn: 148943
|
| |
|
|
|
|
|
|
|
|
| |
"use the new ConstantVector::getSplat method where it makes sense."
Also simplify a bunch of code to use the Builder->getInt32 instead
of doing it the hard and ugly way. Much more progress could be made
here, but I don't plan to do it.
llvm-svn: 148926
|
| |
|
|
| |
llvm-svn: 148923
|
| |
|
|
|
|
|
| |
Original log:
use the new ConstantVector::getSplat method where it makes sense.
llvm-svn: 148907
|
| |
|
|
| |
llvm-svn: 148904
|