This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: PR 11271 Handle reloading of R+R+CONST for any reg


[Sorry for the delay, I was travelling lately too :-)]

> I think there are really two separate issues.  The one is a question of
> optimization: is splitting out the REG + CONST into a separate reload
> beneficial on the particular platform?  On s390, this is likely not to
> be true in the case of (non-base REG + REG + CONST), so I don't want
> that case to hit in any case.

Do you mean that the 3-part address pattern is valid on s390? If so, it's 
indeed partly an optimization issue on that platform. But on SPARC (and on 
arm according to your remark below) it's really only a correctness issue, 
because it's the only place where (REG + REG + CONST_INT) can be untangled 
into the canonical (REG + REG). If it doesn't match here, the compiler ICEs.

> The other issue is a correctness issue: if find_reloads_address decides
> to perform the split, everything should continue to work.  I've looked
> a bit more into why it currently breaks on s390.
> [...]
> Now, what looks broken to me in this scenario is that I thought all
> changes done by find_reloads should be reverted in the
> calculate_needs_all_insns loop, so that each pass through the loop finds
> the original insn again.

<naive question>
How would the loop terminate if the same reloads were scheduled for each
iteration?
</naive question>

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]