This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/4] Add Visium support to gcc
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 03 Jan 2015 16:16:04 +0100
- Subject: Re: [PATCH 3/4] Add Visium support to gcc
- Authentication-results: sourceware.org; auth=none
- References: <1697377 dot F6QTYBSkkH at polaris> <2262251 dot mrrELjuWpe at polaris> <5499C725 dot 70409 at redhat dot com>
> 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