Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2

2012-03-21 Thread Georg-Johann Lay
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

RE: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2

2012-03-21 Thread Weddington, Eric
> -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.

Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2

2012-03-20 Thread Steven Bosscher
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

Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2

2012-03-20 Thread Georg-Johann Lay
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

[Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2

2012-03-20 Thread Georg-Johann Lay
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

Re: [Patch,AVR]: Hack around PR rtl-optimization/52543

2012-03-19 Thread Mike Stump
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

Re: Ping #1: [Patch,AVR]: Hack around PR rtl-optimization/52543

2012-03-19 Thread Denis Chertykov
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.

Ping #1: [Patch,AVR]: Hack around PR rtl-optimization/52543

2012-03-19 Thread 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. > > The TARGET_MODE_DEPENDENT_ADDRESS_P

[Patch,AVR]: Hack around PR rtl-optimization/52543

2012-03-09 Thread Georg-Johann Lay
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,