Steven Bosscher wrote:
> On Tue, Mar 20, 2012 at 8:54 PM, Georg-Johann Lay wrote:
>> Dropping the first patch which does not work because at expand-time there
>> must not be pre-/post-modify addressing :-(
>
> Have you tried to fix that, instead? Or at least ask around a bit to
> see what people
> -Original Message-
> From: Georg-Johann Lay
> Sent: Tuesday, March 20, 2012 1:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take
#2
>
> And here is the patch.
On Tue, Mar 20, 2012 at 8:54 PM, Georg-Johann Lay wrote:
> Dropping the first patch which does not work because at expand-time there
> must not be pre-/post-modify addressing :-(
Have you tried to fix that, instead? Or at least ask around a bit to
see what people would think about that idea? The
And here is the patch...
Georg-Johann Lay wrote:
> Dropping the first patch which does not work because at expand-time there
> must not be pre-/post-modify addressing :-(
>
> This solutions turns completely away from MEM and addressing modes:
> It represents loads from the 16-bits address-spaces
Dropping the first patch which does not work because at expand-time there
must not be pre-/post-modify addressing :-(
This solutions turns completely away from MEM and addressing modes:
It represents loads from the 16-bits address-spaces as UNSPEC.
The code is as expected now with the additional
On Mar 9, 2012, at 10:46 AM, Georg-Johann Lay wrote:
> The problem with the PR is that lower-subreg.c happily splits multi-byte moves
> from address spaces without knowing anything about the additional costs this
> is
> causing.
Nasty, arm hit this sort of problem recently as well, and I've hit t
2012/3/19 Georg-Johann Lay :
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
>
> Georg-Johann Lay wrote:
>> The problem with the PR is that lower-subreg.c happily splits multi-byte
>> moves
>> from address spaces without knowing anything about the additional costs this
>> is
>> causing.
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
Georg-Johann Lay wrote:
> The problem with the PR is that lower-subreg.c happily splits multi-byte moves
> from address spaces without knowing anything about the additional costs this
> is
> causing.
>
> The TARGET_MODE_DEPENDENT_ADDRESS_P
The problem with the PR is that lower-subreg.c happily splits multi-byte moves
from address spaces without knowing anything about the additional costs this is
causing.
The TARGET_MODE_DEPENDENT_ADDRESS_P hook cannot be used for 16-bit addresses
because that hook is not sensitive to address spaces,