summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Mangler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Standardize on MSVC behavior for triples with no environmentReid Kleckner2019-07-081-3/+3
| | | | | | | | | | | | | | | | | | | | | Summary: This makes it so that IR files using triples without an environment work out of the box, without normalizing them. Typically, the MSVC behavior is more desirable. For example, it tends to enable things like constant merging, use of associative comdats, etc. Addresses PR42491 Reviewers: compnerd Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64109 llvm-svn: 365387
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [IR] Avoid the need to prefix MS C++ symbols with '\01'Reid Kleckner2018-03-161-2/+10
| | | | | | | | | | | | | | | | | | | | Now the Windows mangling modes ('w' and 'x') do not do any mangling for symbols starting with '?'. This means that clang can stop adding the hideous '\01' leading escape. This means LLVM debug logs are less likely to contain ASCII escape characters and it will be easier to copy and paste MS symbol names from IR. Finally. For non-Windows platforms, names starting with '?' still get IR mangling, so once clang stops escaping MS C++ names, we will get extra '_' prefixing on MachO. That's fine, since it is currently impossible to construct a triple that uses the MS C++ ABI in clang and emits macho object files. Differential Revision: https://reviews.llvm.org/D7775 llvm-svn: 327734
* CodeGen: handle llvm.used properly for COFFSaleem Abdulrasool2018-01-201-0/+10
| | | | | | | | | `llvm.used` contains a list of pointers to named values which the compiler, assembler, and linker are required to treat as if there is a reference that they cannot see. Ensure that the symbols are preserved by adding an explicit `-include` reference to the linker command. llvm-svn: 323017
* Move llvm::emitLinkerFlagsForGlobalCOFF() to Mangler.Peter Collingbourne2017-03-311-0/+32
| | | | llvm-svn: 299183
* Remove the default constructor and count variable from the Mangler sinceEric Christopher2016-09-291-1/+1
| | | | | | we can just use the size of the DenseMap as a unique counter. llvm-svn: 282674
* Update to use new name alignTo().Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257804
* Remove unused arguments and move ManglerPrefixTy to the implementation.Rafael Espindola2015-06-231-13/+25
| | | | llvm-svn: 240408
* Simplify the Mangler interface now that DataLayout is mandatory.Rafael Espindola2015-06-231-18/+14
| | | | | | | We only need to pass in a DataLayout when mangling a raw string, not when constructing the mangler. llvm-svn: 240405
* Use MCSymbols for FastISel.Rafael Espindola2015-06-231-6/+14
| | | | | | | | | | | The summary is that it moves the mangling earlier and replaces a few calls to .addExternalSymbol with addSym. I originally wanted to replace all the uses of addExternalSymbol with addSym, but noticed it was a lot of work and doesn't need to be done all at once. llvm-svn: 240395
* Revert "Move dllimport name mangling to IR mangler."Reid Kleckner2015-06-111-4/+0
| | | | | | | | | This reverts commit r239437. This broke clang-cl self-hosts. We'd end up calling the __imp_ symbol directly instead of using it to do an indirect function call. llvm-svn: 239502
* Move dllimport name mangling to IR mangler.Peter Collingbourne2015-06-091-0/+4
| | | | | | | | This ensures that LTO clients see the correct external symbol name. Differential Revision: http://reviews.llvm.org/D10318 llvm-svn: 239437
* Revert "Address review comments"David Majnemer2015-03-171-6/+4
| | | | | | This reverts commit r232540. This was committed accidently. llvm-svn: 232541
* Address review commentsDavid Majnemer2015-03-171-4/+6
| | | | llvm-svn: 232540
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Silencing an "enumeral and non-enumeral type in conditional expression" ↵Aaron Ballman2014-10-281-1/+2
| | | | | | warning; NFC. llvm-svn: 220775
* X86: Implement the vectorcall calling conventionReid Kleckner2014-10-281-34/+47
| | | | | | | | | | | | | | | | | | | | This is a Microsoft calling convention that supports both x86 and x86_64 subtargets. It passes vector and floating point arguments in XMM0-XMM5, and passes them indirectly once they are consumed. Homogenous vector aggregates of up to four elements can be passed in sequential vector registers, but this part is not implemented in LLVM and will be handled in Clang. On 32-bit x86, it is similar to fastcall in that it uses ecx:edx as integer register parameters and is callee cleanup. On x86_64, it delegates to the normal win64 calling convention. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D5943 llvm-svn: 220745
* Revert "Don't count inreg params when mangling fastcall functions"Reid Kleckner2014-10-231-3/+0
| | | | | | | | | | This reverts commit r214981. I'm not sure what I was thinking when I wrote this. Testing with MSVC shows that this function is mangled to '@f@8': int __fastcall f(int a, int b); llvm-svn: 220492
* Don't count inreg params when mangling fastcall functionsReid Kleckner2014-08-061-0/+3
| | | | | | This is consistent with MSVC. llvm-svn: 214981
* [pr20127] Check for leading \1 in the Twine version of getNameWithPrefix.Rafael Espindola2014-08-011-8/+8
| | | | | | | No functionality change, but will simplify an upcoming patch that uses the Twine version. llvm-svn: 214515
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-1/+1
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-131-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These linkages were introduced some time ago, but it was never very clear what exactly their semantics were or what they should be used for. Some investigation found these uses: * utf-16 strings in clang. * non-unnamed_addr strings produced by the sanitizers. It turns out they were just working around a more fundamental problem. For some sections a MachO linker needs a symbol in order to split the section into atoms, and llvm had no idea that was the case. I fixed that in r201700 and it is now safe to use the private linkage. When the object ends up in a section that requires symbols, llvm will use a 'l' prefix instead of a 'L' prefix and things just work. With that, these linkages were already dead, but there was a potential future user in the objc metadata information. I am still looking at CGObjcMac.cpp, but at this point I am convinced that linker_private and linker_private_weak are not what they need. The objc uses are currently split in * Regular symbols (no '\01' prefix). LLVM already directly provides whatever semantics they need. * Uses of a private name (start with "\01L" or "\01l") and private linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm agrees with clang on L being ok or not for a given section. I have two patches in code review for this. * Uses of private name and weak linkage. The last case is the one that one could think would fit one of these linkages. That is not the case. The semantics are * the linker will merge these symbol by *name*. * the linker will hide them in the final DSO. Given that the merging is done by name, any of the private (or internal) linkages would be a bad match. They allow llvm to rename the symbols, and that is really not what we want. From the llvm point of view, these objects should really be (linkonce|weak)(_odr)?. For now, just keeping the "\01l" prefix is probably the best for these symbols. If we one day want to have a more direct support in llvm, IMHO what we should add is not a linkage, it is just a hidden_symbol attribute. It would be applicable to multiple linkages. For example, on weak it would produce the current behavior we have for objc metadata. On internal, it would be equivalent to private (and we should then remove private). llvm-svn: 203866
* Add back r201608, r201622, r201624 and r201625Rafael Espindola2014-02-191-6/+13
| | | | | | | | | | | | | | r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
* Revert r201622 and r201608.Daniel Jasper2014-02-191-13/+6
| | | | | | | This causes the LLVMgold plugin to segfault. More information on the replies to r201608. llvm-svn: 201669
* Fix PR18743.Rafael Espindola2014-02-181-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | The IR @foo = private constant i32 42 is valid, but before this patch we would produce an invalid MachO from it. It was invalid because it would use an L label in a section where the liker needs the labels in order to atomize it. One way of fixing it would be to just reject this IR in the backend, but that would not be very front end friendly. What this patch does is use an 'l' prefix in sections that we know the linker requires symbols for atomizing them. This allows frontends to just use private and not worry about which sections they go to or how the linker handles them. One small issue with this strategy is that now a symbol name depends on the section, which is not available before codegen. This is not a problem in practice. The reason is that it only happens with private linkage, which will be ignored by the non codegen users (llvm-nm and llvm-ar). llvm-svn: 201608
* Mark the methods in the Mangler const.Rafael Espindola2014-02-101-5/+6
| | | | | | | | | A const ObjectFile needs to be able to provide its name. For an IRObjectFile, that means being able to call the mangler. Since each IRObjectFile can have a different mangling, it is natural for them to contain a Mangler which is therefore also const. llvm-svn: 201113
* Implement inalloca codegen for x86 with the new inalloca designReid Kleckner2014-01-311-2/+2
| | | | | | | | | | | | | | | | 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
* Use a raw_stream to implement the mangler.Rafael Espindola2014-01-291-61/+73
| | | | | | | | | This is a bit more convenient for some callers, but more importantly, it is easier to implement correctly. Doing this removes the patching of already printed data that was used for fastcall, fixing a crash with private fastcall symbols. llvm-svn: 200367
* Fix fastcall mangling of dllimported symbolsNico Rieck2014-01-141-7/+6
| | | | | | | | | | | | | fastcall requires @ as global prefix instead of _ but getNameWithPrefix wrongly assumes the OutName buffer is empty and replaces at index 0. For imported functions this buffer is pre-filled with "__imp_" resulting in broken "@_imp_foo@0" mangling. Instead replace at the proper index. We also never have to prepend the @-prefix because this fastcall mangling is only used on 32-bit Windows targets which have _ has global prefix. llvm-svn: 199203
* Remove vestigal bits of MC from the mangler. It no longer uses this, andChandler Carruth2014-01-081-1/+0
| | | | | | | having the include could cause weird layering problems between the IR and MC libraries. llvm-svn: 198796
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-071-0/+129
This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
OpenPOWER on IntegriCloud