- 30 Nov, 2012 2 commits
-
-
Pawel Wodnicki authored
Follow up to 168711: It's safe to base this analysis on the found compare, just return the value for the right predicate. Thanks to Andy for catching this. llvm-svn: 168974
-
Pawel Wodnicki authored
SCEV: Even if the latch terminator is foldable we can't deduce the result of an unrelated condition with it. Fixes PR14432. llvm-svn: 168973
-
- 29 Nov, 2012 6 commits
-
-
Pawel Wodnicki authored
Don't use iterator after being erased. llvm-svn: 168947
-
Pawel Wodnicki authored
llvm-svn: 168917
-
Pawel Wodnicki authored
When we have a MemberExpr referring to an overloaded static member function, and we resolve it to a specific function based on the type which it's used as, don't forget to mark it as referenced. Fixes a regression introduced in r167514. llvm-svn: 168888
-
Pawel Wodnicki authored
Avoid rewriting instructions twice. This could cause miscompilations in targets where sub-register composition is not always idempotent (ARM). <rdar://problem/12758887> llvm-svn: 168849
-
Hal Finkel authored
llvm-svn: 168842
-
Hal Finkel authored
llvm-svn: 168839
-
- 28 Nov, 2012 4 commits
-
-
Pawel Wodnicki authored
PR13098: If we're instantiating an overloaded binary operator and we could determine which member function would be the callee from within the template definition, don't pass that function as a "non-member function" to CreateOverloadedBinOp. Instead, just rely on it to select the member function for itself. llvm-svn: 168830
-
Pawel Wodnicki authored
clang/test: Suppress two tests on LLP64 target, Windows x64. llvm-svn: 168823
-
Pawel Wodnicki authored
Fix the definition of the vfork() builtin on Haiku. PR14378. llvm-svn: 168819
-
Pawel Wodnicki authored
Fix crash on end-of-file after \ in a char literal, fixes PR14369. This makes LexCharConstant() look more like LexStringLiteral(), which doesn't have this bug. Add tests for eof after \ for several other cases. llvm-svn: 168808
-
- 27 Nov, 2012 2 commits
-
-
Pawel Wodnicki authored
clang/test/Sema/warn-documentation.cpp: Try to fix up the testcase in r168277. - llvm-svn: 168732
-
Pawel Wodnicki authored
Documentation parsing: propely handle a lone '\endverbatim' and emit a warning. We actually used to assert on this. Thanks to NAKAMURA Takumi for noticing this! llvm-svn: 168730
-
- 26 Nov, 2012 5 commits
-
-
Pawel Wodnicki authored
The ObjC++-to-C++ personality trick is only necessary on NeXT runtimes, which is not coincidentally the only place it works, either (because of how it tests for EH_TYPE symbols). llvm-svn: 168611
-
Pawel Wodnicki authored
Move some GNUStep-specific code out of CGObjCGNU. Patch by Jonathan Schleifer. llvm-svn: 168609
-
Pawel Wodnicki authored
Handle DAG CSE adding new uses during ReplaceAllUsesWith. Fixes PR14333. llvm-svn: 168596
-
Pawel Wodnicki authored
Make this easier to understand, as suggested by Chandler. llvm-svn: 168594
-
Pawel Wodnicki authored
InstructionSimplify should be able to simplify A+B==B+A to 'true' but wasn't due to the same logic bug that caused PR14361. llvm-svn: 168593
-
- 23 Nov, 2012 2 commits
-
-
Pawel Wodnicki authored
Handle mixed normal and early-clobber defs on inline asm. PR14376. llvm-svn: 168527
-
Pawel Wodnicki authored
Update call to the new syntax. llvm-svn: 168526
-
- 22 Nov, 2012 4 commits
-
-
Pawel Wodnicki authored
Fix PR14060, an infinite loop in reassociate. The problem was that one of the operands of the expression being written was wrongly thought to be reusable as an inner node of the expression resulting in it turning up as both an inner node *and* a leaf, creating a cycle in the def-use graph. This would have caused the verifier to blow up if things had gotten that far, however it managed to provoke an infinite loop first. llvm-svn: 168489
-
Pawel Wodnicki authored
Update method calls to the new interface re r168354. llvm-svn: 168487
-
Pawel Wodnicki authored
Make the AttrListPtr object a part of the LLVMContext. When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. llvm-svn: 168486
-
Pawel Wodnicki authored
Don't try to calculate the alignment of an unsigned type. Fixes PR14371! llvm-svn: 168480
-
- 21 Nov, 2012 9 commits
-
-
Pawel Wodnicki authored
llvm-svn: 168465
-
Pawel Wodnicki authored
Set of Attributes patches. Merging r168354: Make the AttrListPtr object a part of the LLVMContext. When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. Merging r168355: Merging r168379 llvm-svn: 168457
-
Pawel Wodnicki authored
Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logic replaced by this patch is equivalent to the new logic, but you'd be wrong, and that's exactly where the bug was. There's a similar bug in instsimplify which manifests itself as instsimplify failing to simplify this, rather than doing it wrong, see next commit. llvm-svn: 168447
-
Pawel Wodnicki authored
Fix a crash observed by Shuxin Yang. The issue here is that LinearizeExprTree, the utility for extracting a chain of operations from the IR, thought that it might as well combine any constants it came across (rather than just returning them along with everything else). On the other hand, the factorization code would like to see the individual constants (this is quite reasonable: it is much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6; you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo multiplications of constants as it may at first appear). This patch therefore makes LinearizeExprTree stupider: it now leaves optimizing to the optimization part of reassociate, and sticks to just analysing the IR. llvm-svn: 168446
-
Pawel Wodnicki authored
Merging r168361: Fix PR14132 and handle OOB loads speculated throuh PHI nodes. The issue is that we may end up with newly OOB loads when speculating a load into the predecessors of a PHI node, and this confuses the new integer splitting logic in some cases, triggering an assertion failure. In fact, the branch in question must be dead code as it loads from a too-narrow alloca. Add code to handle this gracefully and leave the requisite FIXMEs for both optimizing more aggressively and doing more to aid sanitizing invalid code which triggers these patterns. Merging r168346: ------------------------------------------------------------------------ Rework the rewriting of loads and stores for vector and integer allocas to properly handle the combinations of these with split integer loads and stores. This essentially replaces Evan's r168227 by refactoring the code in a different way, and trynig to mirror that refactoring in both the load and store sides of the rewriting. Generally speaking there was some really problematic duplicated code here that led to poorly founded assumptions and then subtle bugs. Now much of the code actually flows through and follows a more consistent style and logical path. There is still a tiny bit of duplication on the store side of things, but it is much less bad. This also changes the logic to never re-use a load or store instruction as that was simply too error prone in practice. I've added a few tests (one a reduction of the one in Evan's original patch, which happened to be the same as the report in PR14349). I'm going to look at adding a few more tests for things I found and fixed in passing (such as the volatile tests in the vectorizable predicate). This patch has survived bootstrap, and modulo one bugfix survived Duncan's test suite, but let me know if anything else explodes. Merging r168227: Teach SROA rewriteVectorizedStoreInst to handle cases when the loaded value is narrower than the stored value. rdar://12713675 llvm-svn: 168443
-
Pawel Wodnicki authored
Preserve address space of forward-referenced global variables in the LL parser Before, the parser would assert on the following code: @a2 = global i8 addrspace(1)* @a @a = addrspace(1) global i8 0 because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing the initializer for @a2. llvm-svn: 168435
-
Pawel Wodnicki authored
Fix a pasto. llvm-svn: 168432
-
Pawel Wodnicki authored
block extended signatur option. Change previous option to a cc1 -fencode-extended-block-signature and pass it to cc1 and recognize this option to produce extended block type signature. // rdar://12109031 llvm-svn: 168419
-
Pawel Wodnicki authored
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168416
-
- 20 Nov, 2012 6 commits
-
-
Andrew Kaylor authored
Merge in r168364 to disable MCJIT execution engine tests on ppc32 (which doesn't currently support MCJIT). llvm-svn: 168392
-
Pawel Wodnicki authored
NVPTXISelLowering.cpp: Fix warnings. [-Wunused-variable] llvm-svn: 168378
-
Hal Finkel authored
llvm-svn: 168353
-
Hal Finkel authored
llvm-svn: 168351
-
Hal Finkel authored
llvm-svn: 168350
-
Hal Finkel authored
llvm-svn: 168349
-