- Nov 15, 2013
-
-
Chandler Carruth authored
pulling them under 80-columns. No functionality changed. llvm-svn: 194856
-
Chad Rosier authored
rather than the vector equivalent. llvm-svn: 194853
-
Rui Ueyama authored
Summary: Make identify_magic to recognize COFF import file. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2165 llvm-svn: 194852
-
Adrian Prantl authored
llvm-svn: 194848
-
Manman Ren authored
We used to use std::map<IndicesVector, LoadInst*> for OriginalLoads, and when we try to promote two arguments, they will both write to OriginalLoads causing created loads for the two arguments to have the same original load. And the same tbaa tag and alignment will be put to the created loads for the two arguments. The fix is to use std::map<std::pair<Argument*, IndicesVector>, LoadInst*> for OriginalLoads, so each Argument will write to different parts of the map. PR17906 llvm-svn: 194846
-
Rui Ueyama authored
0xffff does not mean that there are 65535 sections in a COFF file but indicates that it's a COFF import library. This patch fixes SEGV error when an import library file is passed to llvm-readobj. llvm-svn: 194844
-
Adrian Prantl authored
If getDIE() fails, getOrCreateContextDIE() should also return the CUDie. llvm-svn: 194843
-
Bob Wilson authored
Stop folding constant adds into GEP when the type size doesn't match. Otherwise, the adds' operands are effectively being promoted, changing the conditions of an overflow. Results are different when: sext(a) + sext(b) != sext(a + b) Problem originally found on x86-64, but also fixed issues with ARM and PPC, which used similar code. <rdar://problem/15292280> Patch by Duncan Exon Smith! llvm-svn: 194840
-
Tom Stellard authored
This fixes a crash with GNOME settings manager. llvm-svn: 194836
-
Andrew Kaylor authored
Patch by James Lyon! llvm-svn: 194832
-
Andrew Kaylor authored
Patch by Dale Martin! llvm-svn: 194831
-
Cameron McInally authored
llvm-svn: 194824
-
Daniel Sanders authored
[mips][msa] lowerMSABitClear() should use SelectionDAG::getNOT() instead of using a long-winded equivalent. Now that getConstant(-1, MVT::v2i64) works correctly on MIPS32 we can use SelectionDAG::getNOT() to produce the bitmask. llvm-svn: 194819
-
Alexey Samsonov authored
llvm-svn: 194818
-
Daniel Sanders authored
Summary: When getConstant() is called for an expanded vector type, it is split into multiple scalar constants which are then combined using appropriate build_vector and bitcast operations. In addition to the usual big/little endian differences, the case where the element-order of the vector does not have the same endianness as the elements themselves is also accounted for. For example, for v4i32 on big-endian MIPS, the byte-order of the vector is <3210,7654,BA98,FEDC>. For little-endian, it is <0123,4567,89AB,CDEF>. Handling this case turns out to be a nop since getConstant() returns a splatted vector (so reversing the element order doesn't change the value) This fixes a number of cases in MIPS MSA where calling getConstant() during operation legalization introduces illegal types (e.g. to legalize v2i64 UNDEF into a v2i64 BUILD_VECTOR of illegal i64 zeros). It should also handle bigger differences between illegal and legal types such as legalizing v2i64 into v8i16. lowerMSASplatImm() in the MIPS backend no longer needs to avoid calling getConstant() so this function has been updated in the same patch. For the sake of transparency, the steps I've taken since the review are: * Added 'virtual' to isVectorEltOrderLittleEndian() as requested. This revealed that the MIPS tests were falsely passing because a polymorphic function was not actually polymorphic in the reviewed patch. * Fixed the tests that were now failing. This involved deleting the code to handle the MIPS MSA element-order (which was previously doing an byte-order swap instead of an element-order swap). This left isVectorEltOrderLittleEndian() unused and it was deleted. * Fixed build failures caused by rebasing beyond r194467-r194472. These build failures involved the bset, bneg, and bclr instructions added in these commits using lowerMSASplatImm() in a way that was no longer valid after this patch. Some of these were fixed by calling SelectionDAG::getConstant() instead, others were fixed by a new function getBuildVectorSplat() that provided the removed functionality of lowerMSASplatImm() in a more sensible way. Reviewers: bkramer Reviewed By: bkramer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1973 llvm-svn: 194811
-
Justin Holewinski authored
Using a special machine node is cleaner than an InlineAsm node, and fixes an assertion failure in InstrEmitter llvm-svn: 194810
-
Yaron Keren authored
llvm-svn: 194808
-
Kostya Serebryany authored
llvm-svn: 194800
-
Benjamin Kramer authored
llvm-svn: 194799
-
Zoran Jovanovic authored
llvm-svn: 194792
-
Bob Wilson authored
I was able to successfully run a bootstrapped LTO build of clang with r194701, so this change does not seem to be the cause of our failing buildbots. llvm-svn: 194789
-
Matt Arsenault authored
llvm-svn: 194786
-
Matt Arsenault authored
This is to avoid this transformation in some cases: fold (conv (load x)) -> (load (conv*)x) On architectures that don't natively support some vector loads efficiently casting the load to a smaller vector of larger types and loading is more efficient. Patch by Micah Villmow. llvm-svn: 194783
-
Bob Wilson authored
This reverts commit 194701. Apple's bootstrapped LTO builds have been failing, and this change (along with compiler-rt 194702-194704) is the only thing on the blamelist. I will either reappy these changes or help debug the problem, depending on whether this fixes the buildbots. llvm-svn: 194780
-
Peter Zotov authored
LLVMGetTargetFromName used to compare two char* strings directly. llvm-svn: 194771
-
Peter Zotov authored
llvm-svn: 194770
-
Peter Zotov authored
LLVMGetTargetFromName was not yet present in an LLVM release, so this does not break compatibility. llvm-svn: 194769
-
Reed Kotler authored
short form. Constant islands will expand them if they are out of range. Since there is not direct object emitter at this time, it does not have any material affect because the assembler sorts this out. But we need to know for the actual constant island work. We track the difference by putting # 16 inst in the comments. llvm-svn: 194766
-
Eric Christopher authored
DbgVariable. No functional change. llvm-svn: 194761
-
Matt Arsenault authored
Patch by Michele Scandale! llvm-svn: 194760
-
Tom Stellard authored
The LDS output queue is accessed via the OQAP register. The OQAP register cannot be live across clauses, so if value is written to the output queue, it must be retrieved before the end of the clause. With the machine scheduler, we cannot statisfy this constraint, because it lacks proper alias analysis and it will mark some LDS accesses as having a chain dependency on vertex fetches. Since vertex fetches require a new clauses, the dependency may end up spiltting OQAP uses and defs so the end up in different clauses. See the lds-output-queue.ll test for a more detailed explanation. To work around this issue, we now combine the LDS read and the OQAP copy into one instruction and expand it after register allocation. This patch also adds some checks to the EmitClauseMarker pass, so that it doesn't end a clause with a value still in the output queue and removes AR.X and OQAP handling from the scheduler (AR.X uses and defs were already being expanded post-RA, so the scheduler will never see them). Reviewed-by: Vincent Lejeune <vljn at ovi.com> llvm-svn: 194755
-
Tom Stellard authored
Patch by: Alex Deucher Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> llvm-svn: 194752
-
Andrew Trick authored
This comes into play with patchpoint, which can fold multiple operands. Since the patchpoint is already treated as a call, the machine mem operands won't affect anything, and there's nothing to test. But we still want to do the right thing here to be sure that our MIs obey the rules. llvm-svn: 194750
-
Matt Arsenault authored
llvm-svn: 194749
-
Hans Wennborg authored
This was casuing my release+asserts build on Windows to fail. llvm-svn: 194747
-
- Nov 14, 2013
-
-
Matt Arsenault authored
llvm-svn: 194738
-
David Blaikie authored
llvm-svn: 194737
-
Rui Ueyama authored
Summary: Some machine-type-neutral object files containing only undefined symbols actually do exist in the Windows standard library. Need to recognize them as COFF files. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2164 llvm-svn: 194734
-
Chad Rosier authored
llvm-svn: 194733
-
David Blaikie authored
llvm-svn: 194728
-