search for: m_look_up_ptr_reg_class

...h they don't, obviously, because everything has been selected as data register instructions). Returning the data register class generates a bunch of illegal moves, such as move.l 8(d0), d1. Here, d0 has to be an address register. The root cause of this is instructions that get emitted with the M_LOOK_UP_PTR_REG_CLASS flag, because I have a ptr_rc in my address mode selection patterns for loads and stores. Also, I'm uncertain as to how this custom DR->AR op replacer pass fits into this whole soup and where it is supposed to happen, as I'm still pretty clueless with llvm internals. :) Thanks, Andreas

On Sep 24, 2007, at 1:12 AM, Andreas Fredriksson wrote: > On 9/24/07, Evan Cheng <evan.cheng at apple.com> wrote: > >> I am going to suggest something shocking. :) Since you will end up >> writing a >> bunch of target specific code anyway, you might a well write a target >> specific pass that change generic instructions into data register >> variant

...because > everything has been selected as data register instructions). > > Returning the data register class generates a bunch of illegal moves, > such as move.l 8(d0), d1. Here, d0 has to be an address register. The > root cause of this is instructions that get emitted with the > M_LOOK_UP_PTR_REG_CLASS flag, because I have a ptr_rc in my address > mode selection patterns for loads and stores. I think it should return DR register class. My theory is if all the nodes are already fixed right after selection, scheduling and allocation should just work. > > > Also, I'm uncertain...