summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86FastISel.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [FastISel][X86] Extend support for {s|u}{add|sub|mul}.with.overflow intrinsics.Juergen Ributzka2014-06-101-30/+89
| | | | llvm-svn: 210610
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-281-11/+2
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-1/+1
| | | | llvm-svn: 209040
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-14/+14
| | | | llvm-svn: 207197
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-3/+3
| | | | llvm-svn: 205610
* isTargetWindows() renamed to isTargetKnownWindowsMSVC()Yaron Keren2014-04-011-1/+1
| | | | | | | | to reflect its current functionality. Based on Takumi NAKAMURA suggestion. llvm-svn: 205338
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
* Revert "Prevent alias from pointing to weak aliases."Rafael Espindola2014-03-261-1/+1
| | | | | | | | | This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
* Prune includes in X86 target.Craig Topper2014-03-191-1/+1
| | | | llvm-svn: 204216
* [C++11] Mark the target fast isel classes as 'final' so that the compiler ↵Craig Topper2014-03-181-1/+1
| | | | | | can de-virtualize some of the internal calls. llvm-svn: 204123
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-091-7/+7
| | | | | | class. llvm-svn: 203378
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-041-1/+1
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-041-1/+1
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* Rename a DebugLoc variable to DbgLoc and a DataLayout to DL.Rafael Espindola2014-02-181-80/+83
| | | | | | This is quiet a bit less confusing now that TargetData was renamed DataLayout. llvm-svn: 201606
* Implement inalloca codegen for x86 with the new inalloca designReid Kleckner2014-01-311-0/+4
| | | | | | | | | | | | | | | | Calls with inalloca are lowered by skipping all stores for arguments passed in memory and the initial stack adjustment to allocate argument memory. Now the frontend is responsible for the memory layout, and the backend doesn't have to do any work. As a result these changes are pretty minimal. Reviewers: echristo Differential Revision: http://llvm-reviews.chandlerc.com/D2637 llvm-svn: 200596
* Don't put non-static allocas in the static alloca mapReid Kleckner2014-01-311-0/+1
| | | | | | | | Allocas marked inalloca are never static, but we were trying to put them into the static alloca map if they were in the entry block. Also add an assertion in x86 fastisel. llvm-svn: 200593
* Fix known typosAlp Toker2014-01-241-1/+1
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Add FPExt option to CCValAssign::LocInfo. When generating calling-conventionLang Hames2014-01-141-0/+2
| | | | | | | | | | promotion code, Tablegen will now select FPExt for floating point promotions (previously it had returned AExt, which is not valid for floating point types). Any out-of-tree targets that were relying on AExt being returned for FP promotions will need to update their code check for FPExt instead. llvm-svn: 199252
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-1/+1
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
* Revert "Decouple dllexport/dllimport from linkage"Nico Rieck2014-01-141-1/+1
| | | | | | | | Revert this for now until I fix an issue in Clang with it. This reverts commit r199204. llvm-svn: 199207
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-1/+1
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199204
* [x86] Disambiguate RET[QL] and fix aliases for 16-bit modeDavid Woodhouse2014-01-081-1/+1
| | | | | | | | | | I couldn't see how to do this sanely without splitting RETQ from RETL. Eric says: "sad about the inability to roundtrip them now, but...". I have no idea what that means, but perhaps it wants preserving in the commit comment. llvm-svn: 198756
* [X86][fast-isel] Fix select lowering.Quentin Colombet2013-12-191-2/+7
| | | | | | | | | | The condition in selects is supposed to be i1. Make sure we are just reading the less significant bit of the 8 bits width value to match this constraint. <rdar://problem/15651765> llvm-svn: 197712
* [stackprotector] Use analysis from the StackProtector pass for stack layout ↵Josh Magee2013-12-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | in PEI a nd LocalStackSlot passes. This changes the MachineFrameInfo API to use the new SSPLayoutKind information produced by the StackProtector pass (instead of a boolean flag) and updates a few pass dependencies (to preserve the SSP analysis). The stack layout follows the same approach used prior to this change - i.e., only LargeArray stack objects will be placed near the canary and everything else will be laid out normally. After this change, structures containing large arrays will also be placed near the canary - a case previously missed by the old implementation. Out of tree targets will need to update their usage of MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument. The next patch will implement the rules for sspstrong and sspreq. The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D2158 llvm-svn: 197653
* Switch to the new MingW ABI.Rafael Espindola2013-12-121-1/+1
| | | | | | | GCC 4.7 changed the MingW ABI. On the LLVM side it means that sret functions don't pop the stack. llvm-svn: 197163
* Avoid illegal integer promotion in fastiselBob Wilson2013-11-151-7/+2
| | | | | | | | | | | | | | | | | 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
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-081-0/+1
| | | | | | | | | | | | | | The idea of the AnyReg Calling Convention is to provide the call arguments in registers, but not to force them to be placed in a paticular order into a specified set of registers. Instead it is up tp the register allocator to assign any register as it sees fit. The same applies to the return value (if applicable). Differential Revision: http://llvm-reviews.chandlerc.com/D2009 Reviewed by Andy llvm-svn: 194293
* [X86][FastISel] Add a comment to help understanding changes made in r192636.Quentin Colombet2013-10-221-0/+23
| | | | | | <rdar://problem/15192473> llvm-svn: 193199
* [X86][FastISel] During X86 fastisel, the address of indirect call was resolvedQuentin Colombet2013-10-141-7/+14
| | | | | | | | | | | | | | | through bitcast, ptrtoint, and inttoptr instructions. This is valid only if the related instructions are in that same basic block, otherwise we may reference variables that were not live accross basic blocks resulting in undefined virtual registers. The bug was exposed when both SDISel and FastISel were used within the same function, i.e., one basic block is issued with FastISel and another with SDISel, as demonstrated with the testcase. <rdar://problem/15192473> llvm-svn: 192636
* Followup to r191252.Bill Wendling2013-09-241-113/+127
| | | | | | | | | | Make sure that the code that handles the constant addresses is run for the GEPs. This just refactors that code and then calls it for the GEPs that are collected during the iteration. <rdar://problem/12445434> llvm-svn: 191281
* Selecting the address from a very long chain of GEPs can blow the stack.Bill Wendling2013-09-241-3/+12
| | | | | | | | | | The recursive nature of the address selection code can cause the stack to explode if there is a long chain of GEPs. Convert the recursive bit into a iterative method to avoid this. <rdar://problem/12445434> llvm-svn: 191252
* Replace getValueType().getSimpleVT() with getSimpleValueType(). Also remove ↵Craig Topper2013-08-151-1/+1
| | | | | | one weird cast from MVT->EVT just to call getSimpleVT(). llvm-svn: 188441
* Fix copy and paste bug from r186491 to make v2f64 use MOVAPD/MOVUPD as it ↵Craig Topper2013-07-181-2/+2
| | | | | | should. llvm-svn: 186566
* Teach x86 fast-isel to use AVX opcodes for vector stores when AVX is enabled.Craig Topper2013-07-171-6/+6
| | | | llvm-svn: 186496
* Make x86 fast-isel correctly choose between aligned and unaligned operations ↵Craig Topper2013-07-171-12/+28
| | | | | | for vector stores. Fixes PR16640. llvm-svn: 186491
* Target/X86: Add explicit Win64 and System V/x86-64 calling conventions.Charles Davis2013-07-121-11/+14
| | | | | | | | | | | | | | | Summary: This patch adds explicit calling convention types for the Win64 and System V/x86-64 ABIs. This allows code to override the default, and use the Win64 convention on a target that wants to use SysV (and vice-versa). This is needed to implement the `ms_abi` and `sysv_abi` GNU attributes. Reviewers: CC: llvm-svn: 186144
* X86 fast-isel: Avoid explicit AH subreg reference for [SU]Rem.Jim Grosbach2013-07-091-4/+31
| | | | | | | | | | | | | Explicit references to %AH for an i8 remainder instruction can lead to references to %AH in a REX prefixed instruction, which causes things to blow up. Do the same thing in FastISel as we do for DAG isel and instead shift %AX right by 8 bits and then extract the 8-bit subreg from that result. rdar://14203849 http://llvm.org/bugs/show_bug.cgi?id=16105 llvm-svn: 185899
* DebugInfo: Don't lose unreferenced non-trivial by-value parametersDavid Blaikie2013-06-211-2/+0
| | | | | | | | | | | | A FastISel optimization was causing us to emit no information for such parameters & when they go missing we end up emitting a different function type. By avoiding that shortcut we not only get types correct (very important) but also location information (handy) - even if it's only live at the start of a function & may be clobbered later. Reviewed/discussion by Evan Cheng & Dan Gohman. llvm-svn: 184604
* Use the Copy we defined above here.Eric Christopher2013-06-111-2/+2
| | | | llvm-svn: 183808
* Don't cache the instruction and register info from the TargetMachine, becauseBill Wendling2013-06-071-5/+2
| | | | | | | | the internals of TargetMachine could change. No functionality change intended. llvm-svn: 183571
* X86: use sub-register sequences for MOV*r0 operationsTim Northover2013-05-301-6/+25
| | | | | | | | | | | | Instead of having a bunch of separate MOV8r0, MOV16r0, ... pseudo-instructions, it's better to use a single MOV32r0 (which will expand to "xorl %reg, %reg") and obtain other sizes with EXTRACT_SUBREG and SUBREG_TO_REG. The encoding is smaller and partial register updates can sometimes be avoided. Until recently, this sequence was a barrier to rematerialization though. That should now be fixed so it's an appropriate time to make the change. llvm-svn: 182928
* X86: change zext moves to use sub-register infrastructure.Tim Northover2013-05-301-9/+30
| | | | | | | | | | | | 32-bit writes on amd64 zero out the high bits of the corresponding 64-bit register. LLVM makes use of this for zero-extension, but until now relied on custom MCLowering and other code to fixup instructions. Now we have proper handling of sub-registers, this can be done by creating SUBREG_TO_REG instructions at selection-time. Should be no change in functionality. llvm-svn: 182921
* Move TryToFoldFastISelLoad to FastISel, where it belongs. In general, I'mEli Bendersky2013-04-191-9/+5
| | | | | | | trying to move as much FastISel logic as possible out of the main path in SelectionDAGISel - intermixing them just adds confusion. llvm-svn: 179902
* Allow misaligned stores in x86 fast-isel.Derek Schuff2013-04-181-5/+0
| | | | | | | | | | | | In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and handled by the DAG-based ISel. However, X86FastISel::X86SelectLoad() makes no such requirement. There doesn't appear to be an x86 architectural correctness issue with allowing potentially unaligned store instructions. This patch removes this restriction. Patch by Jim Stichnot. llvm-svn: 179774
* This patch teaches x86 fast-isel to generate the native div/idiv instructionsEli Bendersky2013-04-171-0/+125
| | | | | | | | | for the sdiv/srem/udiv/urem bitcode instructions. This is done for the i8, i16, and i32 types, as well as i64 for the x86_64 target. Patch by Jim Stichnoth llvm-svn: 179715
* [fast-isel] Use the correct API to disable FastLowerArguments for Win64.Chad Rosier2013-04-021-1/+1
| | | | llvm-svn: 178549
* Make Win32 put the SRet address into EAX, fixes PR15556Timur Iskhodzhanov2013-03-281-4/+6
| | | | llvm-svn: 178291
* [fast-isel] The X86FastISel::FastLowerArguments function doesn't properly handleChad Rosier2013-03-141-0/+3
| | | | | | | the win64 calling convention. rdar://13423768 llvm-svn: 177113
* [fast-isel] Make sure the FastLowerArguments function checks to make sure theChad Rosier2013-02-261-0/+1
| | | | | | | arguments type is a simple type. rdar://13290455 llvm-svn: 176066
OpenPOWER on IntegriCloud