summaryrefslogtreecommitdiff
path: root/include/llvm/Target
Commit message (Collapse)AuthorAge
* All backends use MC now.Rafael Espindola2014-01-10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198959 91177308-0d34-0410-b5e6-96231b3b80d8
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-07
| | | | | | This makes it available to tools that don't link with target (like llvm-ar). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198708 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor function that checks that __builtin_returnaddress's argument is ↵Bill Wendling2014-01-06
| | | | | | | | | constant. This moves the check up into the parent class so that all targets can use it without having to copy (and keep in sync) the same error message. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198579 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the llvm mangler depend only on DataLayout.Rafael Espindola2014-01-03
| | | | | | | | | | | | | | Before this patch any program that wanted to know the final symbol name of a GlobalValue had to link with Target. This patch implements a compromise solution where the mangler uses DataLayout. This way, any tool that already links with Target (llc, clang) gets the exact behavior as before and new IR files can be mangled without linking with Target. With this patch the mangler is constructed with just a DataLayout and DataLayout is extended to include the information the Mangler needs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198438 91177308-0d34-0410-b5e6-96231b3b80d8
* Disable compare sinking in CodeGenPrepare when multiple condition registers ↵Hal Finkel2014-01-02
| | | | | | | | | | | | | | | | | | | are available As noted in the comment above CodeGenPrepare::OptimizeInst, which aggressively sinks compares to reduce pressure on the condition register(s), for targets such as PowerPC with multiple condition registers, this may not be the right thing to do. This adds an HasMultipleConditionRegisters boolean to TLI, and CodeGenPrepare::OptimizeInst is skipped when HasMultipleConditionRegisters is true. This functionality will be used by the PowerPC backend in an upcoming commit. Especially when the PowerPC backend starts tracking individual condition register bits as separate allocatable entities (which will happen in this upcoming commit), this sinking from CodeGenPrepare::OptimizeInst is significantly suboptimial. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198354 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for positionally-encoded operands to FixedLenDecoderEmitterHal Finkel2013-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, the PowerPC instruction definitions make heavy use of the positional operand encoding heuristic to map operands onto bitfield variables in the instruction definitions. Changing this to use name-based mapping is not trivial, however, because additional infrastructure needs to be designed to handle mapping of complex operands (with multiple suboperands) onto multiple bitfield variables. In the mean time, this adds support for positionally encoded operands to FixedLenDecoderEmitter, so that we can generate a disassembler for the PowerPC backend. To prevent an accidental reliance on this feature, and to prevent an undesirable interaction with existing disassemblers, a backend must opt-in to this support by setting the new decodePositionallyEncodedOperands instruction-set bit to true. When enabled, this iterates the variables that contribute to the instruction encoding, just as the encoder does, and emulates the procedure the encoder uses to map "numbered" operands to variables. The bit range for each variable is also determined as the encoder determines them. This map is then consulted during the decoder-generator's loop over operands to decode, allowing the decoder to understand both position-based and name-based operand-to-variable mappings. As noted in the comment on the decodePositionallyEncodedOperands definition, this support should be removed once it is no longer needed. There should be no change to existing disassemblers. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197691 91177308-0d34-0410-b5e6-96231b3b80d8
* Enable double to float shrinking optimizations for binary functions like ↵Yi Jiang2013-12-16
| | | | | | 'fmin/fmax'. Fix radar:15283121 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197434 91177308-0d34-0410-b5e6-96231b3b80d8
* Add TargetRegisterInfo::reverseLocalAssignment hook.Andrew Trick2013-12-11
| | | | | | | | | | | | | | This hook reverses the order of assignment for local live ranges. This will generally allocate shorter local live ranges first. For targets with many registers, this could reduce regalloc compile time by a large factor. It should still achieve optimal coloring; however, it can change register eviction decisions. It is disabled by default for two reasons: (1) Top-down allocation is simpler and easier to debug for targets that don't benefit from reversing the order. (2) Bottom-up allocation could result in poor evicition decisions on some targets affecting the performance of compiled code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197001 91177308-0d34-0410-b5e6-96231b3b80d8
* Add TargetLowering::prepareVolatileOrAtomicLoadRichard Sandiford2013-12-10
| | | | | | | | | | | | | | | | | | One unusual feature of the z architecture is that the result of a previous load can be reused indefinitely for subsequent loads, even if a cache-coherent store to that location is performed by another CPU. A special serializing instruction must be used if you want to force a load to be reattempted. Since volatile loads are not supposed to be omitted in this way, we should insert a serializing instruction before each such load. The same goes for atomic loads. The patch implements this at the IR->DAG boundary, in a similar way to atomic fences. It is a no-op for targets other than SystemZ. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196905 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a RequireStructuredCFG Field to TargetMachine.Vincent Lejeune2013-12-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196634 91177308-0d34-0410-b5e6-96231b3b80d8
* Machine model comments. Explain a ProcessorUnit's BufferSize.Andrew Trick2013-12-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196515 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the isImplicitlyPrivate argument of getNameWithPrefix.Rafael Espindola2013-12-05
| | | | | | | | | | | | getSymbolWithGlobalValueBase use is to create a name of a new symbol based on the name of an existing GV. Assert that and then remove the last call to pass true to isImplicitlyPrivate. This gives the mangler API a 1:1 mapping from GV to names, which is what we need to drop the mangler dependency on the target (and use an extended datalayout instead). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196472 91177308-0d34-0410-b5e6-96231b3b80d8
* Correct word hyphenationsAlp Toker2013-12-05
| | | | | | | This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities and contractions in nearby lines. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
* Move getSymbolWithGlobalValueBase to TargetLoweringObjectFile.Rafael Espindola2013-12-02
| | | | | | This allows it to be used in TargetLoweringObjectFileImpl.cpp. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196117 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove dead code.Rafael Espindola2013-12-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196066 91177308-0d34-0410-b5e6-96231b3b80d8
* Change the default of AsmWriterClassName and isMCAsmWriter.Rafael Espindola2013-12-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196065 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor a lot of patchpoint/stackmap related code to simplify and make itLang Hames2013-11-29
| | | | | | | | | | | | | | | | | | | | | | | | target independent. Most of the x86 specific stackmap/patchpoint handling was necessitated by the use of the native address-mode format for frame index operands. PEI has now been modified to treat stackmap/patchpoint similarly to DEBUG_INFO, allowing us to use a simple, platform independent register/offset pair for frame indexes on stackmap/patchpoints. Notes: - Folding is now platform independent and automatically supported. - Emiting patchpoints with direct memory references now just involves calling the TargetLoweringBase::emitPatchPoint utility method from the target's XXXTargetLowering::EmitInstrWithCustomInserter method. (See X86TargetLowering for an example). - No more ugly platform-specific operand parsers. This patch shouldn't change the generated output for X86. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195944 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove dead argument.Rafael Espindola2013-11-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195806 91177308-0d34-0410-b5e6-96231b3b80d8
* StackMap: Implement support for DirectMemRefOp.Andrew Trick2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A Direct stack map location records the address of frame index. This address is itself the value that the runtime requested. This differs from IndirectMemRefOp locations, which refer to a stack locations from which the requested values must be loaded. Direct locations can directly communicate the address if an alloca, while IndirectMemRefOp handle register spills. For example: entry: %a = alloca i64... llvm.experimental.stackmap(i32 <ID>, i32 <shadowBytes>, i64* %a) Since both the alloca and stackmap intrinsic are in the entry block, and the intrinsic takes the address of the alloca, the runtime can assume that LLVM will not substitute alloca with any intervening value. This must be verified by the runtime by checking that the stack map's location is a Direct location type. The runtime can then determine the alloca's relative location on the stack immediately after compilation, or at any time thereafter. This differs from Register and Indirect locations, because the runtime can only read the values in those locations when execution reaches the instruction address of the stack map. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195712 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach ISel not to optimize 'optnone' functions (revised).Paul Robinson2013-11-22
| | | | | | | | | | | | | | Improvements over r195317: - Set/restore EnableFastISel flag instead of just running FastISel within SelectAllBasicBlocks; the flag is checked in various places, and FastISel won't run properly if those places don't do the right thing. - Test looks for normal ISel versus FastISel behavior, and not something more subtle that doesn't work everywhere. Based on work by Andrea Di Biagio. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195491 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace.NAKAMURA Takumi2013-11-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195341 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r195317 (and r195333), "Teach ISel not to optimize 'optnone' functions."NAKAMURA Takumi2013-11-21
| | | | | | | | It broke, at least, i686 target. It is reproducible with "llc -mtriple=i686-unknown". FYI, it didn't appear to add either "-O0" or "-fast-isel". git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195339 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach ISel not to optimize 'optnone' functions.Paul Robinson2013-11-21
| | | | | | | Based on work by Andrea Di Biagio. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195317 91177308-0d34-0410-b5e6-96231b3b80d8
* Added a size field to the stack map record to handle subregister spills.Andrew Trick2013-11-17
| | | | | | | | Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194942 91177308-0d34-0410-b5e6-96231b3b80d8
* Add target hook to prevent folding some bitcasted loads.Matt Arsenault2013-11-15
| | | | | | | | | | | | | This is to avoid this transformation in some cases: fold (conv (load x)) -> (load (conv*)x) On architectures that don't natively support some vector loads efficiently casting the load to a smaller vector of larger types and loading is more efficient. Patch by Micah Villmow. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194783 91177308-0d34-0410-b5e6-96231b3b80d8
* Add addrspacecast instruction.Matt Arsenault2013-11-15
| | | | | | Patch by Michele Scandale! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194760 91177308-0d34-0410-b5e6-96231b3b80d8
* Move the old pass manager infrastructure into a legacy namespace andChandler Carruth2013-11-09
| | | | | | | | | | | | | | | | | | | give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194324 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Materialize the jump address within the patchpoint noop slide.Juergen Ributzka2013-11-09
| | | | | | | | | | | | | | | This patch moves the jump address materialization inside the noop slide. This enables patching of the materialization itself or its complete removal. This patch also adds the ability to define scratch registers that can be used safely by the code called from the patchpoint intrinsic. At least one scratch register is required, because that one is used for the materialization of the jump address. This patch depends on D2009. Differential Revision: http://llvm-reviews.chandlerc.com/D2074 Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194306 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-08
| | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194293 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert comments to documentation comments (// -> ///)Dmitri Gribenko2013-11-05
| | | | | | | Patch by MathOnNapkins git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194093 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert calls to __sinpi and __cospi into __sincospi_stretBob Wilson2013-11-03
| | | | | | | | | | This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193943 91177308-0d34-0410-b5e6-96231b3b80d8
* Lower stackmap intrinsics directly to their target opcode in the DAG builder.Andrew Trick2013-10-31
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193769 91177308-0d34-0410-b5e6-96231b3b80d8
* Update commentMatt Arsenault2013-10-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193651 91177308-0d34-0410-b5e6-96231b3b80d8
* Workaround MSVC 32-bit miscompile of getCondCodeAction.Matt Arsenault2013-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use 32-bit types for the array instead of 64. This should generally be better anyway. In optimized + assert builds, I saw a failure when a cond code / type combination that is never set was loading a non-zero value and hitting the != Promote assert. It turns out when loading the 64-bit value to do the shift, the assembly loads the 2 32-bit halves from non-consecutive addresses. The address the second half of the loaded uint64_t doesn't include the offset of the array in the struct. Instead of being offset + 4, it's just + 4. I'm not entirely sure why this wasn't observed before. setCondCodeAction isn't heavily used by the in-tree targets, and not with the higher valued vector SimpleValueTypes. Only PPC is using one of the > 32 valued types, and that is probably never used by anyone on a 32-bit MSVC compiled host. I ran into this when upgrading LLVM versions, so I guess the value loaded from the nonsense address happened to work out before. No test since I'm not really sure if / how it can be reproduced with the current in tree targets, and it's not supposed to change anything. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193650 91177308-0d34-0410-b5e6-96231b3b80d8
* Move getSymbol to TargetLoweringObjectFile.Rafael Espindola2013-10-29
| | | | | | This allows constructing a Mangler with just a TargetMachine. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193630 91177308-0d34-0410-b5e6-96231b3b80d8
* SelectionDAG: Pass along the original argument/element type in ISD::InputArgTom Stellard2013-10-23
| | | | | | | | | | | | | | | | For some targets, it is useful to be able to look at the original type of an argument without having to dig through the original IR. This also fixes a bug in SelectionDAGBuilder where InputArg.PartOffset was not taking into account the offset of structure elements. Patch by: Justin Holewinski Tom Stellard: - Changed the type of ArgVT to EVT, so it can store non-simple types like v3i32. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193214 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused TargetLowering field.Matt Arsenault2013-10-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193113 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix CodeGen for vectors of pointers with address spaces.Matt Arsenault2013-10-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193112 91177308-0d34-0410-b5e6-96231b3b80d8
* [projects/test-suite] White space and long line fixes.Jack Carter2013-10-17
| | | | | | | No functionality changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192863 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the ExecutionDepsFix pass to handle AVX instructions.Andrew Trick2013-10-14
| | | | | | | | | | | | | | | | | | | | | | | | This pass is needed to break false dependencies. Without it, unlucky register assignment can result in wild (5x) swings in performance. This pass was trying to handle AVX but not getting it right. AVX doesn't have partial register defs, it has unused register reads in which the high bits of a source operand are copied into the unused bits of the dest. Fixing this requires conservative liveness analysis. This is awkard because the pass already has its own pseudo-liveness. However, proper liveness is expensive, and we would like to use a generic utility to compute it. The fix only invokes liveness on-demand. It is rare to detect a case that needs undef-read dependence breaking, but when it happens, it can be needed many times within a very large block. I think the existing heuristic which uses a register window of 16 is too conservative for loop-carried false dependencies. If the loop is a reduction. The out-of-order engine may be able to execute several loop iterations in parallel. However, I'll leave this tuning exercise for next time. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192635 91177308-0d34-0410-b5e6-96231b3b80d8
* [DAGCombiner] Reapply load slicing (192471) with a test that explicitly set ↵Quentin Colombet2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sse4.2 support. This should fix the buildbots. Original commit message: [DAGCombiner] Slice a big load in two loads when the element are next to each other in memory and the target has paired load and performs post-isel loads combining. E.g., this optimization will transform something like this: a = load i64* addr b = trunc i64 a to i32 c = lshr i64 a, 32 d = trunc i64 c to i32 into: b = load i32* addr1 d = load i32* addr2 Where addr1 = addr2 +/- sizeof(i32), if the target supports paired load and performs post-isel loads combining. One should overload TargetLowering::hasPairedLoad to provide this information. The default is false. <rdar://problem/14477220> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192476 91177308-0d34-0410-b5e6-96231b3b80d8
* [DAGCombiner] Revert load slicing (r192471), until I figure out why it fails ↵Quentin Colombet2013-10-11
| | | | | | on ubuntu. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192474 91177308-0d34-0410-b5e6-96231b3b80d8
* [DAGCombiner] Slice a big load in two loads when the element are next to eachQuentin Colombet2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | other in memory and the target has paired load and performs post-isel loads combining. E.g., this optimization will transform something like this: a = load i64* addr b = trunc i64 a to i32 c = lshr i64 a, 32 d = trunc i64 c to i32 into: b = load i32* addr1 d = load i32* addr2 Where addr1 = addr2 +/- sizeof(i32), if the target supports paired load and performs post-isel loads combining. One should overload TargetLowering::hasPairedLoad to provide this information. The default is false. <rdar://problem/14477220> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192471 91177308-0d34-0410-b5e6-96231b3b80d8
* test commitSriram Murali2013-10-10
| | | | | | | | - fix comments on vector type legalization git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192389 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix grammar / missing wordsMatt Arsenault2013-10-10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192380 91177308-0d34-0410-b5e6-96231b3b80d8
* IfConverter: Use TargetSchedule for instruction latenciesArnold Schwaighofer2013-09-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For targets that have instruction itineraries this means no change. Targets that move over to the new schedule model will use be able the new schedule module for instruction latencies in the if-converter (the logic is such that if there is no itineary we will use the new sched model for the latencies). Before, we queried "TTI->getInstructionLatency()" for the instruction latency and the extra prediction cost. Now, we query the TargetSchedule abstraction for the instruction latency and TargetInstrInfo for the extra predictation cost. The TargetSchedule abstraction will internally call "TTI->getInstructionLatency" if an itinerary exists, otherwise it will use the new schedule model. ATTENTION: Out of tree targets! (I will also send out an email later to LLVMDev) This means, if your target implements unsigned getInstrLatency(const InstrItineraryData *ItinData, const MachineInstr *MI, unsigned *PredCost); and returns a value for "PredCost", you now also need to implement unsigned getPredictationCost(const MachineInstr *MI); (if your target uses the IfConversion.cpp pass) radar://15077010 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191671 91177308-0d34-0410-b5e6-96231b3b80d8
* Even more spelling fixes for "instruction".Robert Wilhelm2013-09-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191611 91177308-0d34-0410-b5e6-96231b3b80d8
* Added temp flag -misched-bench for staging in default changes.Andrew Trick2013-09-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191423 91177308-0d34-0410-b5e6-96231b3b80d8
* Mark the x86 machine model as incomplete. PR17367.Andrew Trick2013-09-25
| | | | | | | | | | | | Ideally, the machinel model is added at the time the instructions are defined. But many instructions in X86InstrSSE.td still need a model. Without this workaround the scheduler asserts because x86 already has itinerary classes for these instructions, indicating they should be modeled by the scheduler. Since we use the new machine model for other instructions, it expects a new machine model for these too. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191391 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an instruction deprecation feature to TableGen.Joey Gouly2013-09-12
| | | | | | | | | | | | | | | | | | | | | | | | The 'Deprecated' class allows you to specify a SubtargetFeature that the instruction is deprecated on. The 'ComplexDeprecationPredicate' class allows you to define a custom predicate that is called to check for deprecation. For example: ComplexDeprecationPredicate<"MCR"> would mean you would have to define the following function: bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI, std::string &Info) Which returns 'false' for not deprecated, and 'true' for deprecated and store the warning message in 'Info'. The MCTargetAsmParser constructor was chaned to take an extra argument of the MCInstrInfo class, so out-of-tree targets will need to be changed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190598 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 06:56:32 +0000