summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
* Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-7/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r265765, reapplying r265759 after changing a call from LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug intrinsic operand may no longer be pointing at a local. http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/ The previous coommit message follows: -- This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265768
* Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-35/+7
| | | | | | | | | | | | | This reverts commit r265759, since even this limited version breaks some bots: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696 This also reverts r265761 "ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFC", since I had trouble separating it from r265759. llvm-svn: 265765
* [TargetRegisterInfo] Fix BitMaskClassIterator::moveToNextID implementation.Quentin Colombet2016-04-081-7/+6
| | | | | | | Make sure we do not read past the size of the mask. Although we were not using the value read, this is bad and makes ASan complain. llvm-svn: 265763
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-082-13/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* ValueMapper: Treat LocalAsMetadata more like function-local ValuesDuncan P. N. Exon Smith2016-04-081-7/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265759
* [RegisterBankInfo] Add print and dump method to the InstructionMappingQuentin Colombet2016-04-071-0/+13
| | | | | | helper class. llvm-svn: 265747
* [RegisterBankInfo] Add print and dump method to the ValueMapping helperQuentin Colombet2016-04-071-0/+12
| | | | | | class. llvm-svn: 265746
* [RegisterBankInfo] Escap \@ in r265741. [-Wdocumentation]Quentin Colombet2016-04-071-1/+1
| | | | llvm-svn: 265742
* [RegisterBankInfo] Change the semantic of recordRegBankForType.Quentin Colombet2016-04-071-7/+12
| | | | | | | | Now, recordRegBankForType records only the first register bank that covers a type instead of the last. This behavior can, nevertheless, be override with the additional Force parameter to force the update. llvm-svn: 265741
* llvm-dwarfdump: Use deque rather than vector to preserve object ↵David Blaikie2016-04-072-8/+4
| | | | | | | | | | | | | | reference/pointer identity TUs in each unit refer to the unit they are in, if the unit is moved this reference is invalidated & things break. No test case because UB isn't testable - ASan would likely catch this on a large enough test case (just needs to have enough TUs that a reallocation of the vector would occur) but didn't seem worthwhile. Up for debate/revisiting if anyone feels strongly. llvm-svn: 265740
* [RegisterBankInfo] Add a way to record what register bank covers aQuentin Colombet2016-04-071-4/+38
| | | | | | | | | | | | specific type. This will be used to find the default mapping of the instruction. Also, this information is recorded, instead of computed, because it is expensive from a type to know which register bank maps it. Indeed, we need to iterate through all the register classes of all the register banks to find the one that maps the given type. llvm-svn: 265736
* [RegisterBankInfo] Introduce getRegBankFromConstraints as an helperQuentin Colombet2016-04-071-0/+12
| | | | | | | | | | | method. NFC. The refactoring intends to make the code more readable and expose more features to potential derived classes. llvm-svn: 265735
* Const correctness for BranchProbabilityInfo (NFC)Mehdi Amini2016-04-071-15/+17
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265731
* [TargetRegisterInfo] Introduce a helper class, BitMaskClassIterator, toQuentin Colombet2016-04-071-0/+92
| | | | | | | | | | iterate over register class bitmask. Thanks to this helper class, it would not require for each user of the register classes bitmask to actually know how they are represents. Moreover, it will make the code much easier to read. llvm-svn: 265730
* [RegBankSelect] Reuse RegisterBankInfo logic to get to the register bankQuentin Colombet2016-04-071-0/+4
| | | | | | | | | from a register. On top of duplicating the logic, it was buggy! It would assert on physical registers, since MachineRegisterInfo does not have any information regarding register classes/banks for them. llvm-svn: 265727
* [TargetRegisterInfo] Fix the comment of SuperRegClassIterator::getMask.Quentin Colombet2016-04-071-1/+2
| | | | llvm-svn: 265721
* [GlobalISel] Add RegBankSelect hooks into the pass pipeline.Quentin Colombet2016-04-071-0/+9
| | | | | | | Now, RegBankSelect will happen after the IRTranslation and the target may optionally add additional passes in between. llvm-svn: 265716
* [RegBankSelect] Initial implementation for non-optimized output.Quentin Colombet2016-04-071-16/+49
| | | | | | | | The pass walk through the machine function and assign the register banks using the default mapping. In other words, there is no attempt to reduce cross register copies. llvm-svn: 265707
* [RegisterBankInfo] Add more details on the expectation ofQuentin Colombet2016-04-071-0/+5
| | | | | | getInstrMapping. llvm-svn: 265704
* [RegisterBankInfo] Provide a target independent helper function to guessQuentin Colombet2016-04-071-0/+36
| | | | | | | | | | | | | the mapping of an instruction on register bank. For most instructions, it is possible to guess the mapping of the instruciton by using the encoding constraints. It remains instructions without encoding constraints. For copy-like instructions, we try to propagate the information we get from the other operands. Otherwise, the target has to give this information. llvm-svn: 265703
* [RegisterBankInfo] Change the signature of getSizeInBits to factor outQuentin Colombet2016-04-071-0/+1
| | | | | | the access to MRI and TRI. llvm-svn: 265701
* [RegisterBankInfo] Provide a default constructor for InstructionMappingQuentin Colombet2016-04-071-0/+17
| | | | | | | | | helper class. The default constructor creates invalid (isValid() == false) instances and may be used to communicate that a mapping was not found. llvm-svn: 265699
* [MachineRegisterInfo] Track register bank for virtual registers.Quentin Colombet2016-04-071-3/+57
| | | | | | | | | | | | | | | | | | | | A virtual register may have either a register bank or a register class. This is represented by a PointerUnion between the related classes. Typically, a virtual register went through the following states regarding register class and register bank: 1. Creation: None is set. Virtual registers are fully generic. 2. Register bank assignment: Register bank is set. Virtual registers live into a register bank, but we do not know the constraints they need to fulfil. 3. Instruction selection: Register class is set. Virtual registers are bound by encoding constraints. To map these states to GlobalISel, the IRTranslator implements #1, RegBankSelect #2, and Select #3. llvm-svn: 265696
* [RegisterBank] Rename RegisterBank::contains into RegisterBank::covers.Quentin Colombet2016-04-071-2/+2
| | | | llvm-svn: 265695
* NFC: disallow comparison of AtomicOrderingJF Bastien2016-04-071-0/+5
| | | | | | Follow-up to D18775 and related clang change. AtomicOrdering is a lattice, 'stronger' is the right thing to do, direct comparison is fraught with peril. llvm-svn: 265685
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-0710-3/+139
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValuesDuncan P. N. Exon Smith2016-04-071-1/+2
| | | | | | | | | Remove the assertion that disallowed the combination, since RF_IgnoreMissingLocals should have no effect on globals. As it happens, RF_NullMapMissingGlobalValues asserted in MapValue(Constant*,...), so I also changed a cast to a cast_or_null to get my test passing. llvm-svn: 265633
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-071-3/+20
| | | | | | | | | | | | | | | | | | | | | | | Clarify what this RemapFlag actually means. - Change the flag name to match its intended behaviour. - Clearly document that it's not supposed to affect globals. - Add a host of FIXMEs to indicate how to fix the behaviour to match the intent of the flag. RF_IgnoreMissingLocals should only affect the behaviour of RemapInstruction for function-local operands; namely, for operands of type Argument, Instruction, and BasicBlock. Currently, it is *only* passed into RemapInstruction calls (and the transitive MapValue calls that it makes). When I split Metadata from Value I didn't understand the flag, and I used it in a bunch of places for "global" metadata. This commit doesn't have any functionality change, but prepares to cleanup MapMetadata and MapValue. llvm-svn: 265628
* ValueMapper: clang-format ValueMapper.h, NFCDuncan P. N. Exon Smith2016-04-061-91/+92
| | | | | | Also remove duplicated identifiers from comments. llvm-svn: 265611
* [llvm-c] Add LLVMGetValueKind.Peter Zotov2016-04-061-0/+38
| | | | | | | | Patch by Nicole Mazzuca <npmazzuca@gmail.com>. Differential Revision: http://reviews.llvm.org/D18729 llvm-svn: 265608
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-065-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
* [RegisterBankInfo] Add methods to get the possible mapping of an instruction ↵Quentin Colombet2016-04-061-0/+53
| | | | | | | | | | | | | | | | | | | | | | | on a register bank. This will be used by the register bank select pass to assign register banks for generic virtual registers. This was originally committed as r265573 but broke at least one windows bot. The problem with the windows bot was that it was using a copy constructor for the InstructionMappings class and could not synthesize it. Actually, the fact that this class is not copy constructable is expected and the compiler should use the move assignment constructor. Marking the problematic assignment explicitly as using the move constructor has its own problems. Indeed, with recent clang we get a warning that we may prevent the elision of the copy by the compiler. A proper fix for both compilers would be to change the API of getPossibleInstrMapping to take a InstructionMappings as input/output parameter. This does not feel natural and since GISel is not used on windows yet, I chose to workaround the problem by not compiling the problematic code on windows. llvm-svn: 265604
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-063-42/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* AMDGPU: Add a shader calling conventionNicolai Haehnle2016-04-061-0/+12
| | | | | | | | | | | This makes it possible to distinguish between mesa shaders and other kernels even in the presence of compute shaders. Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Differential Revision: http://reviews.llvm.org/D18559 llvm-svn: 265589
* Revert "[RegisterBankInfo] Add methods to get the possible mapping of anQuentin Colombet2016-04-061-84/+0
| | | | | | | | | | | instruction on a register bank. This will be used by the register bank select pass to assign register banks for generic virtual registers." and the follow-on commits while I find out a way to fix the win7 bot: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19882 This reverts commit r265578, r265581, r265584, and r265585. llvm-svn: 265587
* [RegisterBankInfo] Get rid of the assert in the constructor of ↵Quentin Colombet2016-04-061-2/+0
| | | | | | | | | InstructionMapping. The default constructor now uses the regular constructor and the assert is not valid anymore. llvm-svn: 265585
* [RegisterBankInfo] Call the other constructor of InstructionMapping from theQuentin Colombet2016-04-061-1/+1
| | | | | | | | | default constructor, instead of relying on the default constructor of unique_ptr. Second attempt at fixing the windows bot. llvm-svn: 265584
* [gold] Save bitcode for module partitions (save-temps + split codegen).Evgeniy Stepanov2016-04-061-1/+5
| | | | llvm-svn: 265583
* [RegisterBankInfo] Provide a default constructor for InstructionMappingQuentin Colombet2016-04-061-0/+17
| | | | | | | | | helper class. The default constructor creates invalid (isValid() == false) instances and may be used to communicate that a mapping was not found. llvm-svn: 265581
* IR: Use DenseSet instead of DenseMap for ConstantUniqueMap; NFCDuncan P. N. Exon Smith2016-04-061-0/+15
| | | | | | | | | | | | | | | | | | Use a DenseSet instead of a DenseMap for constants in LLVMContextImpl. Last time I looked at this was some time before r223588, when DenseSet<V> had no advantage over DenseMap<V,char>. After r223588, there's a 50% memory savings. This is all mechanical. There were little bits of missing API from DenseSet so I added the trivial implementations: - iterator::operator++(int) - template <class LookupKeyT> insert_as(ValueTy, LookupKeyT) There should be no functionality change, just reduced memory consumption (this wasn't on a profile or anything; just a cleanup I stumbled on). llvm-svn: 265577
* [RegisterBankInfo] Add a method to get the mapping RegClass -> RegBank.Quentin Colombet2016-04-061-0/+17
| | | | | | This should be TableGen'ed at some point. llvm-svn: 265574
* [RegisterBankInfo] Add methods to get the possible mapping of an instruction ↵Quentin Colombet2016-04-061-0/+69
| | | | | | | | | on a register bank. This will be used by the register bank select pass to assign register banks for generic virtual registers. llvm-svn: 265573
* [RegisterBankInfo] Make the destructor public... that may be useful!Quentin Colombet2016-04-061-2/+3
| | | | llvm-svn: 265565
* [RegisterBankInfo] Implement the verify method of the InstructionMapping ↵Quentin Colombet2016-04-061-1/+1
| | | | | | | | helper class. This checks that all the register operands get a proper mapping. llvm-svn: 265563
* Loop Unroll: add options and tweak to make Partial unrolling more usefulFiona Glaser2016-04-061-0/+4
| | | | | | | | | | | | | | | | 1. Add FullUnrollMaxCount option that works like MaxCount, but also limits the unroll count for fully unrolled loops. So if a loop has an iteration count over this, it won't fully unroll. 2. Add CLI options for MaxCount and the new option, so they can be tested (plus a test). 3. Make partial unrolling obey MaxCount. An example use-case (the out of tree one this is originally designed for) is a target’s TTI can analyze a loop and decide on a max unroll count separate from the size threshold, e.g. based on register pressure, then constrain LoopUnroll to not exceed that, regardless of the size of the unrolled loop. llvm-svn: 265562
* [MachineRegisterInfo] Document what is the expected metric for the size of ↵Quentin Colombet2016-04-061-2/+2
| | | | | | generic registers llvm-svn: 265561
* [RegisterBankInfo] Implement the verify method for the ValueMapping helper ↵Quentin Colombet2016-04-061-2/+2
| | | | | | | | | class. The method checks that the value is fully defined accross the different partial mappings and that the partial mappings are compatible between each other. llvm-svn: 265556
* [RegisterBankInfo] Add a verify method for the PartialMapping helper class.Quentin Colombet2016-04-061-0/+5
| | | | | | | This verifies that the PartialMapping can be accomadated into the related register bank. llvm-svn: 265555
* [RegisterBankInfo] Add a couple of helper classes for the future cost model.Quentin Colombet2016-04-061-0/+98
| | | | llvm-svn: 265553
* [RegisterBankInfo] Inline the destructor to avoid link-time error when ↵Quentin Colombet2016-04-061-1/+12
| | | | | | GlobalISel is not built. llvm-svn: 265548
OpenPOWER on IntegriCloud