Bingfeng Mei wrote: > I think I found the cause. find_reloads_address returns 0 even > it reloads both parts of address (see the patch). Therefore, > corresponding address_reloaded[i] is not set and in > the following code of find_reloads, > > if (EXTRA_CONSTRAINT_STR (operand, c, p)) > win = 1; > /* If the address was already reloaded, > we win as well. */ > else if (MEM_P (operand) > && address_reloaded[i] == 1) <-- address_reloaded[i] still 0 > win = 1; > ... > > Extra reload is thus generated even it is unnecessary > and causes ICE.
As Ian said, since the address wasn't *completely* reloaded (so that after reload we'll have just a plain base register), it is correct that address_reloaded must be 0. However, if you're running into problems in this part of the code, you may probably hit another of the long-standing warts in reload: at this point, you have an address that reload has already decided to reload certain parts of, and the result has to match one of your port's extra memory constraints. However, reload at this point has not actually made any modifications to the address in its RTL form, it has just recorded in its own tables that *later*, it *will* replace some subexpressions of that RTL with registers. This means that the RTL that is passed to your EXTRA_CONSTRAINT_STR implementation will still be the *original* un-reloaded address. And most likely, your back-end will then reject this address as not valid for your machine. The way some ports take around this issue is to recognize, in your EXTRA_CONSTRAINT_STR implementation, certain forms of complex addresses as those which you *know* reload will already have marked for reloading, and therefore *accept* them (if they'd otherwise match the constraint). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com