search for: armexpandpseudos

Things like this in `lib/Target/ARM/ARMExpandPseudoInsts.cpp` FunctionPass *llvm::createARMExpandPseudoPass() { > return new ARMExpandPseudo(); > } And other functions have basically the same style. What's the point of doing it this way instead of just calling `new ARMExpandPseudo` in any place that you would have called this function? -- Ahmed Samara M.S. Computer Engineering

On 16 January 2018 at 20:40, Ahmed Samara via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Things like this in `lib/Target/ARM/ARMExpandPseudoInsts.cpp` > >> FunctionPass *llvm::createARMExpandPseudoPass() { >> return new ARMExpandPseudo(); >> } > > And other functions have basically the same style. > > What's the point of doing it this way instead

...or expects to be able to insert a copy instruction w/o side-effects, though, and not having one can potentially cause problems. Jakob would be able to more specifically comment on what's required there. Off the top of my head, I'd consider leaving the copy instructions as pseudos until the ARMExpandPseudos pass. Keep track there of whether the CPSR is live and when we see a copy, do whatever tricks we can to try to use a good instruction, including reordering instructions if necessary and possible. That seems a bit heavyweight though, so hopefully someone has a better idea. -Jim On Jan 7, 2012, at...

Hi, I've been thinking about ways to get around this in the short term for some time, http://llvm.org/bugs/show_bug.cgi?id=1388 An end-user workaround is possibly to use at least one register > r7 for the MOV form of the instruction. In that case, what is listed in the bug as the CPY instruction (which is the ARMv6 version generated if both Rd and Rm are <= r7) will become a valid MOV

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

So, taking PR25526 as context, and after reading the internet, it seems to me that creating an atomic LL/SC loop at the IR level -- as is the modern way to do it in LLVM -- is effectively impossible to do correctly. Nor, for that matter, was it correct to create such a loop at isel time, as the implementation prior to r205525 did (and, as some targets still do, not having been updated yet to use