On 05/18/2012 09:16 AM, H.J. Lu wrote: > On Thu, May 17, 2012 at 1:46 PM, Meador Inge <mead...@codesourcery.com> wrote: >> On 05/17/2012 03:02 PM, Richard Sandiford wrote: >> >>> After agonising over this for a couple of days, I think it's probably >>> the correct fix. What we're doing now would be valid if the only use of >>> equiv_constant(x) were to substitute for x. The name and current use >>> of the function obviously require equality though. >>> >>> Patch is OK, thanks. It might be worth extending fold_rtx and >>> equiv_constant to set a flag that says whether the returned value >>> is equivalent or simply one of many valid replacement values. >>> We'd then be able to replace uses of registers like 142 with 0, >>> while not replacing uses of 0 with 142. I don't know how much it >>> would buy us though. That kind of thing is probably more of a job >>> for fwprop. >> >> Thanks for the review. >> >>> Please add UL to the hex constants in the testcase. Not sure whether >>> it matters for 16-bit int targets or not, but better safe than sorry :-) >> >> Fixed. >> >>> Also, rather than: >>> >>>> + /* Otherwise see if we already have a constant for the inner REG. >>>> + Don't bother with paradoxical subregs because we have no way >>>> + of knowing what the upper bytes are. */ >>> >>> how about: >>> >>> /* Otherwise see if we already have a constant for the inner REG, >>> and if that is enough to calculate an equivalent constant for >>> the subreg. Note that the upper bits of paradoxical subregs >>> are undefined, so they cannot be said to equal anything. */ >> >> Sounds good to me. >> >> v2 OK? If so, would you mind committing for me? I don't have write access. >> > > The test fails on Linux/x86 and Linux/x86-64.
I will look into it. Thanks. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
