search for: armexpandpseudo

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 functio...

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 of just calling `new > ARMExpandPseudo` in any pl...

...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

...loating-point, branches), the entire loop must fit within some amount of contiguous memory, and it must only execute a small number of instructions. I see no way that those properties can be guaranteed in LLVM, without emitting the entire loop as a fixed blob. For ARM, there's the newly-added ARMExpandPseudo::ExpandCMP_SWAP code, which basically does that. But, it seems kinda ugly, and a bit horrible to have to write all that code to generate a couple instructions -- and that's only handling cmpxchg, not atomicrmw, which would need similar treatment. And, even with all that, it's still creating...