This flag applies to G_PTR_ADD instructions and indicates that the operation implements an inbounds getelementptr operation, i.e., the pointer operand is in bounds wrt. the allocated object it is based on, and the arithmetic does not change that. It is set when the IRTranslator lowers inbounds GEPs (currently only in some cases, to be extended with a future PR), and in the (build|materialize)ObjectPtrOffset functions. Inbounds information is useful in ISel when we have instructions that perform address computations whose intermediate steps must be in the same memory region as the final result. A follow-up patch will start using it for AMDGPU's flat memory instructions, where the immediate offset must not affect the memory aperture of the address. This is analogous to a concurrent effort in SDAG: #131862 (related: #140017, #141725). For SWDEV-516125.
- Change MachineInstr operand accessors to use `ArrayRef` internally to
slice the operand array into sub-arrays.
- Minor: remove unnecessary {} on `MachineInstrBuilder::add`.
I noticed these destructors taking time with -ftime-trace and moved some of them for minor build efficiency improvements. The main impact of moving destructors out of line is that it avoids requiring container fields containing other types from being complete, i.e. one can have uptr<T> or vector<T> as a field with an incomplete type T, and that means we can reduce transitive includes, as with LegalizerInfo.h. Move expensive getDebugOperandsForReg template out-of-line. The std::function instantiation shows up in time trace even if you don't use the function.
The primary effect of this is that we get proper scalable sizes printed by the assembler, but this may also enable proper aliasing analysis. I don't see any test changes resulting from the later. Getting the size is slightly tricky as we store the scalable size as a non-scalable quantity in the object size field for the frame index. We really should remove that hack at some point... For the synthetic tuple spills and fills, I dropped the size from the split loads and stores to avoid incorrect (overly large) sizes. We could also divide by the NF factor if we felt like writing the code to do so.
As previously discussed [1], it is sometimes useful to be able to see instruction addresses and debug locations as part of IR dumps. The same applies to MachineInstrs which already dump debug locations but not addresses. Therefore add some flags that can be used to enable dumping of this information. [1] https://discourse.llvm.org/t/small-improvement-to-llvm-debugging-experience/79914 Reviewers: rnk Reviewed By: rnk Pull Request: https://github.com/llvm/llvm-project/pull/127944
Even if an inline asm doesn't have memory effects, we can't assume it's safe to speculate: it could trap, or cause undefined behavior. At the LLVM IR level, this is handled correctly: we don't speculate inline asm (unless it's marked "speculatable", but I don't think anyone does that). Codegen also needs to respect this restriction. This change stops Early If Conversion and similar passes from speculating an INLINEASM MachineInstr. Some uses of isSafeToMove probably could be switched to a different API: isSafeToMove assumes you're hoisting, but we could handle some forms of sinking more aggressively. But I'll leave that for a followup, if it turns out to be relevant. See also discussion on gcc bugtracker https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150 .
Remove `TargetIntrinsicInfo` class as its practically unused (its pure virtual with no subclasses) and its references in the code.
[[Change-Id: Ic349022bb99ef91f5396e462ade0366bc772ae02](https://github.com/llvm/llvm-project/pull/123531)](https://github.com/llvm/llvm-project/pull/123531) moved isDead() from DeadMachineInstrElim to MachineInstr . In the process of moving, I reordered the checks to improve chances of early exit, but this has caused a slight increase in compile time. This PR reverts back to the original order of checks.