On Aug 1, 2012, at 16:04 , Ulrich Weigand wrote:
> I've been wondering about mode_dependent_address_p myself. It currently
> appears to cover two quite separate questions:
>
> - If I have a valid address, will it remain valid if I change its mode to
> something else?
>
> - If I have a valid ad
Olivier Hainque wrote:
> I had made a proposal to help the rs6000_mode_dependent_address
> issue, http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
>
> Seems to me that the general idea is still valid:
>
> << a number of places in the compiler use the
>mode_dependent_address_p predica
On Aug 1, 2012, at 13:18 , Alan Modra wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
> I like the idea.
:-)
> It is worth pursuing for code improvement we'll see
> even if we avoid the "o" constraint everywhere. For example,
> long long llo (long long *x) { return x
On Wed, Aug 01, 2012 at 10:26:50AM +0200, Olivier Hainque wrote:
> I had made a proposal to help the rs6000_mode_dependent_address
> issue, http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
>
> Seems to me that the general idea is still valid:
>
> << a number of places in the compiler use
On Jul 17, 2012, at 17:34 , Alan Modra wrote:
> The ICE is
>
> combine.c:5318:1: error: insn does not satisfy its constraints:
> (insn 4211 1484 1493 140 (set (mem/c:DI (plus:SI (reg/f:SI 19 19 [2736])
>(const_int 32760 [0x7ff8])) [3 __gcov0.subst+816 S8 A64])
>(reg:DI 6 6
Alan Modra wrote:
> However, the "o" constraint rejects any offset >= 0x7ff4 due to
> rs6000_mode_dependent_address. This particular problem has been known
> for a long time, but that's not the only problem with "o" (and also
> the rs6000 "Y" constraint, a variant of "o"). A more subtle
> requir
