summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAge
...
* [x86] Allow segment and address-size overrides for MOVS[BWLQ] (PR9385)David Woodhouse2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199807 91177308-0d34-0410-b5e6-96231b3b80d8
* ]x86] Allow segment and address-size overrides for CMPS[BWLQ] (PR9385)David Woodhouse2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199806 91177308-0d34-0410-b5e6-96231b3b80d8
* [x86] Allow address-size overrides for SCAS{8,16,32,64} (PR9385)David Woodhouse2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199805 91177308-0d34-0410-b5e6-96231b3b80d8
* [x86] Allow address-size overrides for STOS[BWLQ] (PR9385)David Woodhouse2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199804 91177308-0d34-0410-b5e6-96231b3b80d8
* [x86] Allow segment and address-size overrides for LODS[BWLQ] (PR9385)David Woodhouse2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199803 91177308-0d34-0410-b5e6-96231b3b80d8
* Loop strength reduce: fix function name.Tim Northover2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199801 91177308-0d34-0410-b5e6-96231b3b80d8
* AVX512: combining setcc and zext is wrong on AVX512Elena Demikhovsky2014-01-22
| | | | | | | because vector compare instruction puts result in mask register. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199798 91177308-0d34-0410-b5e6-96231b3b80d8
* MachineCopyPropagation has special logic for removing COPY instructions. It ↵James Molloy2014-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | will remove plain COPYs using eraseFromParent(), but if the COPY has imp-defs/imp-uses it will convert it to a KILL, to keep the imp-def around. This actually totally breaks and causes the machine verifier to cry in several cases, one of which being: %RAX<def> = COPY %RCX<kill> %ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill> These subregister copies are together identified as noops, so are both removed. However, the second one as it has an imp-use gets converted into a kill: %ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill> As the original COPY has been removed, the verifier goes into tears at the use of undefined EAX and RAX. There are several hacky solutions to this hacky problem (which is all to do with imp-use/def weirdnesses), but the least hacky I've come up with is to *always* remove COPYs by converting to KILLs. KILLs are no-ops to the code generator so the generated code doesn't change (which is why they were partially used in the first place), but using them also keeps the def/use and imp-def/imp-use chains alive: %RAX<def> = KILL %RCX<kill> %ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill> The patch passes all test cases including the ones that check the removal of MOVs in this circumstance, along with an extra test I added to check subregister behaviour (which made the machine verifier fall over before my patch). The patch also adds some DEBUG() statements because the file hadn't got any. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199797 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64 NEON] Try to generate CONCAT_VECTOR when lowering BUILD_VECTOR or ↵Kevin Qin2014-01-22
| | | | | | SHUFFLE_VECTOR. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199791 91177308-0d34-0410-b5e6-96231b3b80d8
* Reformat a loop for basic hygeine. Self review.Andrew Trick2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199788 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sparc] Add support for inline assembly constraints which specify registers ↵Venkatraman Govindaraju2014-01-22
| | | | | | by their aliases. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199786 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix typoMatt Arsenault2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199784 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sparc] Add support for inline assembly constraint 'I'. Venkatraman Govindaraju2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199781 91177308-0d34-0410-b5e6-96231b3b80d8
* Change createObjectFile to return an ErrorOr.Rafael Espindola2014-01-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199776 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sparc] Do not add PC to _GLOBAL_OFFSET_TABLE_ address to access GOT in ↵Venkatraman Govindaraju2014-01-22
| | | | | | | | | absolute code. Fixes PR#18521 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199775 91177308-0d34-0410-b5e6-96231b3b80d8
* [SROA] Fix a bug which could cause the common type finding to returnChandler Carruth2014-01-21
| | | | | | | | | | | | | inconsistent results for different orderings of alloca slices. The fundamental issue is that it is just always a mistake to return early from this function. There is no effective early exit to leverage. This patch stops trynig to do so and simplifies the code a bit as a consequence. Original diagnosis and patch by James Molloy with some name tweaks by me in part reflecting feedback from Duncan Smith on the mailing list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199771 91177308-0d34-0410-b5e6-96231b3b80d8
* Be a bit more consistent about using ErrorOr when constructing Binary objects.Rafael Espindola2014-01-21
| | | | | | | | | | | | | | | | | | | | | | | The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199770 91177308-0d34-0410-b5e6-96231b3b80d8
* CodeGen: Stop treating vectors as aggregatesDuncan P. N. Exon Smith2014-01-21
| | | | | | | | | Fix a crash in SjLjEHPrepare::lowerIncomingArguments caused by treating VectorType like an aggregate. It's first-class! <rdar://problem/15854596> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199768 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix PR18572 - llc crash during GenericScheduler::initPolicy().Andrew Trick2014-01-21
| | | | | | | Generalized the heuristic that looks at the (very rough) size of the register file before enabling regpressure tracking. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199766 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix pointer info on PPC byval storesHal Finkel2014-01-21
| | | | | | | | | | | For PPC64 SVR (and Darwin), the stores that take byval aggregate parameters from registers into the stack frame had MachinePointerInfo objects with incorrect offsets. These offsets are relative to the object itself, not to the stack frame base. This fixes self hosting on PPC64 when compiling with -enable-aa-sched-mi. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199763 91177308-0d34-0410-b5e6-96231b3b80d8
* Adding new LTO APIs to parse metadata nodes and extract linker options andYunzhong Gao2014-01-21
| | | | | | | | | | dependent libraries from a bitcode module. Differential Revision: http://llvm-reviews.chandlerc.com/D2343 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199759 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename these methods to match the style guide.Rafael Espindola2014-01-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199751 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IILoad into II_L[BHWD], II_L[BHW]U, II_L[WD][LR], and ↵Daniel Sanders2014-01-21
| | | | | | | | | | II_RESTORE No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199749 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFmoveC1 into II_M[FT]C1, II_M[FT]HC1, II_DM[FT]C1Daniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199748 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFStore into II_S[WD]C1, and II_S[WDU]XC1Daniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199747 91177308-0d34-0410-b5e6-96231b3b80d8
* [NVPTX] Add missing patterns for div.approx with immediate denominatorJustin Holewinski2014-01-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199746 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFLoad into II_L[WD]C1, and II_L[WDU]XC1Daniel Sanders2014-01-21
| | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199743 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Removed IIFrecipFsqrtStep. No instructions use it.Daniel Sanders2014-01-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199742 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Renamed II_FsqrtSingle and II_FsqrtDouble to II_SQRT_S and ↵Daniel Sanders2014-01-21
| | | | | | | | | | II_SQRT_D respectively No functional change git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199741 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Renamed II_FdivSingle and II_FdivDouble to II_DIV_S and ↵Daniel Sanders2014-01-21
| | | | | | | | | | II_DIV_D respectively No functional change git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199738 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFmulDouble into II_MUL_D, II_MADD_D, II_MSUB_D, ↵Daniel Sanders2014-01-21
| | | | | | | | | | II_NMADD_D, and II_NMSUB_S No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199737 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFmulSingle into II_MUL_S, II_MADD_S, II_MSUB_S, ↵Daniel Sanders2014-01-21
| | | | | | | | | | II_NMADD_S, and II_NMSUB_S No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199734 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFadd into II_ADD_[DS], II_SUB_[DS]Daniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199732 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFcmp into II_C_CC_[SD]Daniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199728 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFmove into II_C[FT]C1, II_MOV[FNTZ]_[SD], II_MOV_[SD]Daniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199727 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIFcvt into II_(ROUND|TRUNC|CEIL|FLOOR|CVT), II_ABS, II_NEGDaniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199722 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips][sched] Split IIslt into II_SLT_SLTU, II_SLTI_SLTIUDaniel Sanders2014-01-21
| | | | | | | | No functional change since the InstrItinData's have been duplicated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199719 91177308-0d34-0410-b5e6-96231b3b80d8
* Checked return warning from coverityRenato Golin2014-01-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199716 91177308-0d34-0410-b5e6-96231b3b80d8
* ARM IAS: add support for .unwind_raw directiveSaleem Abdulrasool2014-01-21
| | | | | | | | | | | | This implements the unwind_raw directive for the ARM IAS. The unwind_raw directive takes the form of a stack offset value followed by one or more bytes representing the opcodes to be emitted. The opcode emitted will interpreted as if it were assembled by the opcode assembler via the standard unwinding directives. Thanks to Logan Chien for an extra test! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199707 91177308-0d34-0410-b5e6-96231b3b80d8
* ARM IAS: support .personalityindexSaleem Abdulrasool2014-01-21
| | | | | | | | | | | | | The .personalityindex directive is equivalent to the .personality directive with the ARM EABI personality with the specific index (0, 1, 2). Both of these directives indicate personality routines, so enhance the personality directive handling to take into account personalityindex. Bonus fix: flush the UnwindContext at the beginning of a new function. Thanks to Logan Chien for additional tests! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199706 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64 NEON] Fix a bug caused by undef lane when generating VEXT.Kevin Qin2014-01-21
| | | | | | | | It was commited as r199628 but reverted in r199628 as causing regression test failed. It's because of old vervsion of patch I used to commit. Sorry for mistake. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199704 91177308-0d34-0410-b5e6-96231b3b80d8
* Tweak the MCExternalSymbolizer to not use the SymbolLookUp() call backKevin Enderby2014-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to not guess at a symbol name in some cases. The problem is that in object files assembled starting at address 0, when trying to symbolicate something that starts like this: % cat x.s _t1: vpshufd $0x0, %xmm1, %xmm0 the symbolic disassembly can end up like this: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $_t1, %xmm1, %xmm0 Which is in this case produced incorrect symbolication. But it is useful in some cases to use the SymbolLookUp() call back to guess at some immediate values. For example one like this that does not have an external relocation entry: % cat y.s _t1: movl $_d1, %eax .data _d1: .long 0 % clang -c -arch i386 y.s % otool -tV y.o y.o: (__TEXT,__text) section _t1: 0000000000000000 movl $_d1, %eax % otool -rv y.o y.o: Relocation information (__TEXT,__text) 1 entries address pcrel length extern type scattered symbolnum/value 00000001 False long False VANILLA False 2 (__DATA,__data) So the change is based on it is not likely that an immediate Value coming from an instruction field of a width of 1 byte, other than branches and items with relocation, are not likely symbol addresses. With the change the first case above simply becomes: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $0x0, %xmm1, %xmm0 and the second case continues to work as expected. rdar://14863405 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199698 91177308-0d34-0410-b5e6-96231b3b80d8
* To allow the X86 verbose assembly to print its informative commentsKevin Enderby2014-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when used with symbolic disassembly, add a check that the operand is an immediate and has not been symbolicated to MCExpr operand. I’m trying to enable the ‘C’ disassembly API option LLVMDisassembler_Option_SetInstrComments for darwin’s otool(1) that uses the llvm disassembler API. The problem is that the disassembler API can change an immediate operand to an MCExpr operand if it symbolicates it with the call backs. And if it does the code in llvm::EmitAnyX86InstComments() will crash when it assumes these operands are immediates. The fix for this is very straight forward to just protect the call to getImm() with a check of isImm(). So if the immediate for an instruction is symbolicated it simply doesn’t get the X86 verbose assembly comments: % otool -tV test_asm.o test_asm.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $_t1, %xmm1, %xmm0 0000000000000005 retq 0000000000000006 nopw %cs:_t1(%rax,%rax) _t2: 0000000000000010 vpshufd $-0x1, %xmm0, %xmm0 ## xmm0 = xmm0[3,3,3,3] 0000000000000015 retq 0000000000000016 nopw %cs:_t1(%rax,%rax) _t3: 0000000000000020 vpshufd $_t1, %xmm1, %xmm0 0000000000000025 retq 0000000000000026 nopw %cs:_t1(%rax,%rax) _t4: 0000000000000030 vpshufd $0x2d, %xmm0, %xmm0 ## xmm0 = xmm0[1,3,2,0] 0000000000000035 retq The fact that the immediate $0x0 is being symbolicated at all in this case is a different problem which my next patch will address. rdar://10989286 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199697 91177308-0d34-0410-b5e6-96231b3b80d8
* Update StackProtector when coloring merges stack slotsHal Finkel2014-01-20
| | | | | | | | | | | | | | | | StackProtector keeps a ValueMap of alloca instructions to layout kind tags for use by PEI and other later passes. When stack coloring replaces one alloca with a bitcast to another one, the key replacement in this map does not work. Instead, provide an interface to manage this updating directly. This seems like an improvement over the old behavior, where the layout map would not get updated at all when the stack slots were merged. In practice, however, there is likely no observable difference because PEI only did anything special with 'large array' kinds, and if one large array is merged with another, than the replacement should already have been a large array. This is an attempt to unbreak the clang-x86_64-darwin11-RA builder. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199684 91177308-0d34-0410-b5e6-96231b3b80d8
* [X86] Teach how to combine a vselect into a movss/movsdAndrea Di Biagio2014-01-20
| | | | | | | | | | | | | | | | | | | | | Add target specific rules for combining vselect dag nodes into movss/movsd when possible. If the vector type of the vselect dag node in input is either MVT::v4i13 or MVT::v4f32, then try to fold according to rules: 1) fold (vselect (build_vector (0, -1, -1, -1)), A, B) -> (movss A, B) 2) fold (vselect (build_vector (-1, 0, 0, 0)), A, B) -> (movss B, A) If the vector type of the vselect dag node in input is either MVT::v2i64 or MVT::v2f64 (and we have SSE2), then try to fold according to rules: 3) fold (vselect (build_vector (0, -1)), A, B) -> (movsd A, B) 4) fold (vselect (build_vector (-1, 0)), A, B) -> (movsd B, A) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199683 91177308-0d34-0410-b5e6-96231b3b80d8
* Debug info: On ARM ensure that all __TEXT sections come before theAdrian Prantl2014-01-20
| | | | | | | | | optional DWARF sections, so compiling with -g does not result in different code being generated for PC-relative loads. This is reapplying a diet r197922 (__TEXT-only). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199681 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Debug info: On ARM ensure that the data sections come before the"Adrian Prantl2014-01-20
| | | | | | | | | Cut back on the cargo cult. The order of __DATA sections doesn't affect generated code. This reverts commit r197922. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199680 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow SMUL_LOHI and UMUL_LOHI to be narrow to MUL on targets where MUL is ↵Owen Anderson2014-01-20
| | | | | | Custom rather than Legal. Even if the target is doing some kind of expansion for MUL, it's pretty much guaranteed to be more efficent than whatever it does for SMUL_LOHI or UMUL_LOHI! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199678 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the useless pseudo instructions VDUPfdf and VDUPfqf, replacing them ↵James Molloy2014-01-20
| | | | | | with patterns to match VDUPLN. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199675 91177308-0d34-0410-b5e6-96231b3b80d8
* Update IR when merging slots in stack coloringHal Finkel2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way that stack coloring updated MMOs when merging stack slots, while correct, is suboptimal, and is incompatible with the use of AA during instruction scheduling. The solution, which involves the use of const_cast (and more importantly, updating the IR from within an MI-level pass), obviously requires some explanation: When the stack coloring pass was originally committed, the code in ScheduleDAGInstrs::buildSchedGraph tracked possible alias sets by using GetUnderlyingObject, and all load/store and store/store memory control dependencies where added between SUs at the object level (where only one object, that returned by GetUnderlyingObject, was used to identify the object associated with each MMO). When stack coloring merged stack slots, it would replace MMOs derived from the remapped alloca with the alloca with which the remapped alloca was being replaced. Because ScheduleDAGInstrs only used single objects, and tracked alias sets at the object level, this was a fine solution. In r169744, (Andy and) I updated the code in ScheduleDAGInstrs to use GetUnderlyingObjects, and track alias sets using, potentially, multiple underlying objects for each MMO. This was done, primarily, to provide the ability to look through PHIs, and provide better scheduling for induction-variable-dependent loads and stores inside loops. At this point, the MMO-updating code in stack coloring became suboptimal, because it would clear the MMOs for (i.e. completely pessimize) all instructions for which r169744 might help in scheduling. Updating the IR directly is the simplest fix for this (and the one with, by far, the least compile-time impact), but others are possible (we could give each MMO a small vector of potential values, or make use of a remapping table, constructed from MFI, inside ScheduleDAGInstrs). Unfortunately, replacing all MMO values derived from the remapped alloca with the base replacement alloca fundamentally breaks our ability to use AA during instruction scheduling (which is critical to performance on some targets). The reason is that the original MMO might have had an offset (either constant or dynamic) from the base remapped alloca, and that offset is not present in the updated MMO. One possible way around this would be to use GetPointerBaseWithConstantOffset, and update not only the MMO's value, but also its offset based on the original offset. Unfortunately, this solution would only handle constant offsets, and for safety (because AA is not completely restricted to deducing relationships with constant offsets), we would need to clear all MMOs without constant offsets over the entire function. This would be an even worse pessimization than the current single-object restriction. Any other solution would involve passing around a vector of remapped allocas, and teaching AA to use it, introducing additional complexity and overhead into AA. Instead, when remapping an alloca, we replace all IR uses of that alloca as well (optionally inserting a bitcast as necessary). This is even more efficient that the old MMO-updating code in the stack coloring pass (because it removes the need to call GetUnderlyingObject on all MMO values), removes the single-object pessimization in the default configuration, and enables the correct use of AA during instruction scheduling (all without any additional overhead). LLVM now no longer miscompiles itself on x86_64 when using -enable-misched -enable-aa-sched-mi -misched-bottomup=0 -misched-topdown=0 -misched=shuffle! Fixed PR18497. Because the alloca replacement is now done at the IR level, unless the MMO directly refers to the remapped alloca, the change cannot be seen at the MI level. As a result, there is no good way to fix test/CodeGen/X86/pr14090.ll. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199658 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 11:49:11 +0000