summaryrefslogtreecommitdiffstats
path: root/llvm/docs/BitCodeFormat.rst
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'"Reid Kleckner2014-05-091-2/+0
| | | | | | | | | | | | | | This reverts commit r200561. This calling convention was an attempt to match the MSVC C++ ABI for methods that return structures by value. This solution didn't scale, because it would have required splitting every CC available on Windows into two: one for methods and one for free functions. Now that we can put sret on the second arg (r208453), and Clang does that (r208458), revert this hack. llvm-svn: 208459
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Test commit - remove trailing whitespaceStephan Tolksdorf2014-03-131-1/+1
| | | | llvm-svn: 203834
* [ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'Reid Kleckner2014-01-311-0/+2
| | | | | | | | | | | | | | | | | | | | MSVC always places the 'this' parameter for a method first. The implicit 'sret' pointer for methods always comes second. We already implement this for __thiscall by putting sret parameters on the stack, but __cdecl methods require putting both parameters on the stack in opposite order. Using a special calling convention allows frontends to keep the sret parameter first, which avoids breaking lots of assumptions in LLVM and Clang. Fixes PR15768 with the corresponding change in Clang. Reviewers: ributzka, majnemer Differential Revision: http://llvm-reviews.chandlerc.com/D2663 llvm-svn: 200561
* Add two new calling conventions for runtime callsJuergen Ributzka2014-01-171-0/+2
| | | | | | | | | | | | | | This patch adds two new target-independent calling conventions for runtime calls - PreserveMost and PreserveAll. The target-specific implementation for X86-64 is defined as following: - Arguments are passed as for the default C calling convention - The same applies for the return value(s) - PreserveMost preserves all GPRs - except R11 - PreserveAll preserves all GPRs and all XMMs/YMMs - except R11 Reviewed by Lang and Philip llvm-svn: 199508
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-3/+15
| | | | | | | | | | | | | | | | | | | 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-15/+3
| | | | | | | | 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-3/+15
| | | | | | | | | | | | | | | | | | | 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
* [anyregcc] Fix callee-save mask for anyregccJuergen Ributzka2014-01-111-0/+2
| | | | | | | Use separate callee-save masks for XMM and YMM registers for anyregcc on X86 and select the proper mask depending on the target cpu we compile for. llvm-svn: 198985
* Implement function prefix data as an IR feature.Peter Collingbourne2013-09-161-1/+4
| | | | | | | | | Previous discussion: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html Differential Revision: http://llvm-reviews.chandlerc.com/D1191 llvm-svn: 190773
* docs: Fix long standing linking antipattern.Sean Silva2013-01-111-2/+0
| | | | | | | | | Before we learned about :doc:, we used :ref: and put a dummy link at the top of each page. Don't do that anymore. This fixes PR14891 as a special case. llvm-svn: 172162
* Better 80cols... *sigh*Joe Abbey2012-11-201-3/+3
| | | | llvm-svn: 168373
* Fixing a broken link.Joe Abbey2012-11-201-3/+3
| | | | llvm-svn: 168372
* Fix a typo in bitcode docs, from 165814.Jan Wen Voung2012-10-151-1/+1
| | | | llvm-svn: 165944
* Add bitcode instruction encoding documentation for module versionJan Wen Voung2012-10-121-1/+48
| | | | | | 0 and 1. Followup to 165739. llvm-svn: 165814
* Sphinxify the bitcode format document.Bill Wendling2012-06-281-0/+1045
llvm-svn: 159340
OpenPOWER on IntegriCloud