arsenm wrote: > > That might work, but that also is more limiting. > > I think it is a good thing. All target-independent pseudo instructions should > have the same semantics across all targets, otherwise they become > target-dependent. If a target can override a standard pseudo instruction in > any way it wishes, then there is nothing in common between these instructions > across targets except for the opcode. This makes them unsuitable for use in > generic code.
> > The instructions from the list have few uses in generic code. It looks like > the point in introducing them was to guarantee they have certain properties. > If a target can override the properties or get them wrong accidentally, it > creates opportunities for bugs to creep in. > > > In particular that doesn't allow you to set implicit uses / defs like you > > would want for adjcallstack pseudos > > Those are no different from other target-specific instructions IMO. They just > happen to have similar names on most targets. To make the argument more > obvious/convincing, consider CALL instruction, which goes in the same row. > All targets have call instructions, but does that fact alone makes CALL > plausible for promotion? I don't think so. Call instructions are too > different across targets and most targets have multiple variants of them. No, there can be many call instructions. The call stack pseudos are special because they have to https://github.com/llvm/llvm-project/pull/159880 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
