aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/TargetMachineC.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-08-12Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer1-3/+2
If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
2016-05-18Delete Reloc::Default.Rafael Espindola1-2/+1
Having an enum member named Default is quite confusing: Is it distinct from the others? This patch removes that member and instead uses Optional<Reloc> in places where we have a user input that still hasn't been maped to the default value, which is now clear has no be one of the remaining 3 options. llvm-svn: 269988
2016-02-16Restore the capability to manipulate datalayout from the C APIAmaury Sechet1-0/+4
Summary: This consist in variosu addition to the C API: LLVMTargetDataRef LLVMGetModuleDataLayout(LLVMModuleRef M); void LLVMSetModuleDataLayout(LLVMModuleRef M, LLVMTargetDataRef DL); LLVMTargetDataRef LLVMCreateTargetMachineData(LLVMTargetMachineRef T); Reviewers: joker.eph, Wallbraker, echristo Subscribers: axw Differential Revision: http://reviews.llvm.org/D17255 llvm-svn: 260936
2016-02-13Support: Fix incremental build when re-configuring targetsDuncan P. N. Exon Smith1-1/+1
r180893 added an indirect include of llvm/Config/Targets.def to llvm/Support/CodeGen.h, which in turn is included by things like llvm/IR/Module.h. After a full build of LLVM and Clang, ninja had to rebuild 1274 files after reconfiguring. This commit strips CodeGen.h back down to just a pile of enums and moves the expensive includes over to CodeGenCWrappers.h (which is only included in two places). This gets ninja down to 88 files if you reconfigure with, e.g., -DLLVM_TARGETS_TO_BUILD=X86. llvm-svn: 260835
2016-02-12C API: Remove LLVMGetDataLayout that was deprecated in 3.7Mehdi Amini1-14/+0
From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260657
2015-08-26Fix LLVM C API for DataLayoutMehdi Amini1-20/+15
We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246082
2015-08-26Revert "Fix LLVM C API for DataLayout"Mehdi Amini1-8/+22
This reverts commit r246052. Third attempt, still unpleasant for some bots. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246057
2015-08-26Fix LLVM C API for DataLayoutMehdi Amini1-22/+8
We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246052
2015-08-26Revert "Fix LLVM C API for DataLayout"Mehdi Amini1-8/+22
This reverts commit r246044. Build broken, still. It builds for me... From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246049
2015-08-26Fix LLVM C API for DataLayoutMehdi Amini1-22/+8
We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 246044
2015-08-25Revert "Fix LLVM C API for DataLayout"Mehdi Amini1-8/+22
This reverts commit 433bfd94e4b7e3cc3f8b08f8513ce47817941b0c. Broke some bot, have to see why it passed locally. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 245917
2015-08-25Fix LLVM C API for DataLayoutMehdi Amini1-22/+8
We removed access to the DataLayout on the TargetMachine and deprecated the C API function LLVMGetTargetMachineData() in r243114. However the way I tried to be backward compatible was broken: I changed the wrapper of the TargetMachine to be a structure that includes the DataLayout as well. However the TargetMachine is also wrapped by the ExecutionEngine, in the more classic way. A client using the TargetMachine wrapped by the ExecutionEngine and trying to get the DataLayout would break. It seems tricky to solve the problem completely in the C API implementation. This patch tries to address this backward compatibility in a more lighter way in the C++ API. The C API is restored in its original state and the removed C++ API is reintroduced, but privately. The C API is friended to the TargetMachine and should be the only consumer for this API. Reviewers: ributzka Differential Revision: http://reviews.llvm.org/D12263 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 245916
2015-08-13Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren1-1/+0
After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
2015-07-27Fix ODR violation. NFC.Diego Novillo1-4/+4
There is an ODR conflict between lib/ExecutionEngine/ExecutionEngineBindings.cpp and lib/Target/TargetMachineC.cpp. The inline definitions should simply be marked static (thanks dblaikie for the hint). llvm-svn: 243298
2015-07-24Remove access to the DataLayout in the TargetMachineMehdi Amini1-13/+17
Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243114
2015-07-24Revert "Remove access to the DataLayout in the TargetMachine"Mehdi Amini1-17/+13
This reverts commit 0f720d984f419c747709462f7476dff962c0bc41. It breaks clang too badly, I need to prepare a proper patch for clang first. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243089
2015-07-24Remove access to the DataLayout in the TargetMachineMehdi Amini1-13/+17
Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243083
2015-06-16Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders1-1/+1
TargetMachine::getTargetTriple(). NFC. Summary: This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10381 llvm-svn: 239815
2015-05-11Readdress r236990, use of static members on a non-static variable.David Blaikie1-9/+6
The TargetRegistry is just a namespace-like class, instantiated in one place to use a range-based for loop. Instead, expose access to the registry via a range-based 'targets()' function instead. This makes most uses a bit awkward/more verbose - but eventually we should just add a range-based find_if function which will streamline these functions. I'm happy to mkae them a bit awkward in the interim as encouragement to improve the algorithms in time. llvm-svn: 237059
2015-04-14Use raw_pwrite_stream in the object writer/streamer.Rafael Espindola1-1/+1
The ELF object writer will take advantage of that in the next commit. llvm-svn: 234950
2015-04-09Simplify use of formatted_raw_ostream.Rafael Espindola1-5/+3
formatted_raw_ostream is a wrapper over another stream to add column and line number tracking. It is used only for asm printing. This patch moves the its creation down to where we know we are printing assembly. This has the following advantages: * Simpler lifetime management: std::unique_ptr * We don't compute column and line number of object files :-) llvm-svn: 234535
2015-04-09Use a raw_svector_ostream instead of a raw_string_ostream.Rafael Espindola1-6/+8
It saves a bit of copying. llvm-svn: 234507
2015-04-09This reverts commit r234460 and r234461.Rafael Espindola1-3/+1
Revert "Add classof implementations to the raw_ostream classes." Revert "Use the cast machinery to remove dummy uses of formatted_raw_ostream." The underlying issue can be fixed without classof. llvm-svn: 234495
2015-04-09Use the cast machinery to remove dummy uses of formatted_raw_ostream.Rafael Espindola1-1/+3
If we know we are producing an object, we don't need to wrap the stream in a formatted_raw_ostream anymore. llvm-svn: 234461
2015-03-04Make DataLayout Non-Optional in the ModuleMehdi Amini1-2/+1
Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
2015-02-13[PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth1-2/+2
LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
2015-02-12Remove mostly unused setters.Rafael Espindola1-1/+1
Most of the code was setting the TargetOptions directly. llvm-svn: 228961
2015-02-01[multiversion] Implement the old pass manager's TTI wrapper pass inChandler Carruth1-1/+2
terms of the new pass manager's TargetIRAnalysis. Yep, this is one of the nicer bits of the new pass manager's design. Passes can in many cases operate in a vacuum and so we can just nest things when convenient. This is particularly convenient here as I can now consolidate all of the TargetMachine logic on this analysis. The most important change here is that this pushes the function we need TTI for all the way into the TargetMachine, and re-creates the TTI object for each function rather than re-using it for each function. We're now prepared to teach the targets to produce function-specific TTI objects with specific subtargets cached, etc. One piece of feedback I'd love here is whether its worth renaming any of this stuff. None of the names really seem that awesome to me at this point, but TargetTransformInfoWrapperPass is particularly ... odd. TargetIRAnalysisWrapper might make more sense. I would want to do that rename separately anyways, but let me know what you think. llvm-svn: 227731
2015-01-31[PM] Switch the TargetMachine interface from accepting a pass managerChandler Carruth1-1/+2
base which it adds a single analysis pass to, to instead return the type erased TargetTransformInfo object constructed for that TargetMachine. This removes all of the pass variants for TTI. There is now a single TTI *pass* in the Analysis layer. All of the Analysis <-> Target communication is through the TTI's type erased interface itself. While the diff is large here, it is nothing more that code motion to make types available in a header file for use in a different source file within each target. I've tried to keep all the doxygen comments and file boilerplate in line with this move, but let me know if I missed anything. With this in place, the next step to making TTI work with the new pass manager is to introduce a really simple new-style analysis that produces a TTI object via a callback into this routine on the target machine. Once we have that, we'll have the building blocks necessary to accept a function argument as well. llvm-svn: 227685
2015-01-26Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher1-2/+2
derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
2014-09-10Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola1-1/+1
With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
2014-08-25Modernize raw_fd_ostream's constructor a bit.Rafael Espindola1-4/+4
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error. A create static method would be even better, but this patch is already a bit too big. llvm-svn: 216393
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-2/+3
information and update all callers. No functional change. llvm-svn: 214781
2014-06-26Revert "Introduce a string_ostream string builder facilty"Alp Toker1-5/+7
Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
2014-06-26Introduce a string_ostream string builder faciltyAlp Toker1-7/+5
string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
2014-05-13[un]wrap extracted from lib/Target/Target[MachineC].cpp, ↵Artyom Skrobov1-17/+0
lib/ExecutionEngine/ExecutionEngineBindings.cpp into include/llvm/IR/DataLayout.h llvm-svn: 208680
2014-04-29raw_ostream: Forward declare OpenFlags and include FileSystem.h only where ↵Benjamin Kramer1-0/+1
necessary. llvm-svn: 207593
2014-04-25[C++] Use 'nullptr'. Target edition.Craig Topper1-2/+2
llvm-svn: 207197
2014-02-25Use DataLayout from the module when easily available.Rafael Espindola1-1/+2
Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
2014-02-25Make DataLayout a plain object, not a pass.Rafael Espindola1-1/+1
Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
2014-02-24Replace the F_Binary flag with a F_Text one.Rafael Espindola1-1/+1
After this I will set the default back to F_None. The advantage is that before this patch forgetting to set F_Binary would corrupt a file on windows. Forgetting to set F_Text produces one that cannot be read in notepad, which is a better failure mode :-) llvm-svn: 202052
2014-01-23Add target analysis passes to the codegen pipeline for MCJIT.Juergen Ributzka1-0/+4
This patch adds the target analysis passes (usually TargetTransformInfo) to the codgen pipeline. We also expose now the AddAnalysisPasses method through the C API, because the optimizer passes would also benefit from better target-specific cost models. Reviewed by Andrew Kaylor llvm-svn: 199926
2014-01-07Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth1-1/+1
subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
2013-11-15[llvm-c] Make LLVMGetTargetFromName actually workPeter Zotov1-1/+2
LLVMGetTargetFromName used to compare two char* strings directly. llvm-svn: 194771
2013-11-15[llvm-c] Add missing const qualifiers to LLVMCreateTargetMachinePeter Zotov1-3/+4
llvm-svn: 194770
2013-11-15[llvm-c] Simplify signature of LLVMGetTargetFromNamePeter Zotov1-7/+4
LLVMGetTargetFromName was not yet present in an LLVM release, so this does not break compatibility. llvm-svn: 194769
2013-11-06[llvm-c] Improve TargetMachine bindingsPeter Zotov1-0/+39
Original patch by Chris Wailes llvm-svn: 194143
2013-10-17llvm-c: Don't assert in LLVMTargetMachineEmitToFile on nonexistent fileAnders Waldenborg1-1/+1
Error handling code for raw_fd_ostream constructor is present, but never used, because formatted_raw_ostream will always assert on closed fd's before. Patch by Peter Zotov Differential Revision: http://llvm-reviews.chandlerc.com/D1909 llvm-svn: 192881
2013-10-17llvm-c: Return NULL from LLVMGetFirstTarget instead of assertingAnders Waldenborg1-2/+6
If no targets are registered, LLVMGetFirstTarget currently fails with an assertion. This patch makes it return NULL instead, similarly to how LLVMGetNextTarget would. Patch by Peter Zotov Differential Revision: http://llvm-reviews.chandlerc.com/D1908 llvm-svn: 192878
2013-07-16Add a wrapper for open.Rafael Espindola1-1/+1
This centralizes the handling of O_BINARY and opens the way for hiding more differences (like how open behaves with directories). llvm-svn: 186447
generated by cgit v1.1 at 2025-10-15 09:51:02 +0000