> I don't see anything particularly offensive. Actually it looks like a > reasonably clean RISC port.
Thanks for the review. > I'm a little concerned about the MODES_TIEABLE_P definition, but if it's > working, I wouldn't mess with it. Could you elaborate? Do you find it too restrictive? > Any thoughts on using LRA for this port? Ideally we want to be moving > away from reload as much as we can. I can only promise to start experimenting with it and report issues, if any. The port is quite mature and the performances are closely monitored so bold changes need to be made with extra caution. > I didn't look closely, do you need blockage insns in your epilogue/prologue? No, I don't think so. > For the prologue, if you store callee saved registers using the frame > pointer, then you need a blockage to ensure those stores don't bubble up > before the local stack gets allocated. And you need something analogous > in the epilogue. I didn't check your port carefully for this, but I'd > advise doing so. The register saves in the prologue are based on the stack pointer because the frame pointer is established only at the very end and its value comprises the allocation. The restores in the epilogue are also based on the stack pointer and the stack_restore and stack_pop patterns which do the deallocation have an explicit memory barrier. > Presumably you're going to be the maintainer for this port? Yes, I'm going to be the maintainer for now. > I think this is good to go into the trunk. The blockage issue (if it's > an issue) can be resolved as a follow-up. OK, thanks again. -- Eric Botcazou
