[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types

["hutchinsonandy at aim dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #8 from hutchinsonandy at aim dot com  2008-04-16 13:10 -------
Subject: Re:  [4.3 Regression] [avr] code bloat caused by
 -fsplit-wide-types

Yes, indeed, I have patches in progress for AVR  that do split 
operation to take more advantage of lowering but the "bug" is still an 
issue then.

For example, if the testcase was using PLUS instead or OR, I will not 
be able to split instruction. (anything with carried "status" is 
problematic with reload and - as yet - cannot be split)

The  problem will merely propagate backwards until it gets blocked by 
unsplit wide mode operation (PLUS, COMPARE, SUB, MULT and probabley 
calls). Simply put, it will occur where ever a wide mode value meets a 
set of subregs. Here it will determine there is a conflict - even if 
there is not one.





-----Original Message-----
From: steven at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
To: hutchinsonandy@aim.com
Sent: Wed, 16 Apr 2008 4:59 am
Subject: [Bug target/35860] [4.3 Regression] [avr] code bloat caused by 
-fsplit-wide-types




------- Comment #7 from steven at gcc dot gnu dot org  2008-04-16 08:59 
-------
I agree with Paolo in comment #6.  One purpose of the lower-subreg path 
was to
allow backends to *not* define insns that it doesn't have.  The 
expanders will
generate inline code for such patterns at expand time, with sets to 
subregs.
Before GCC had lower-subreg, this would lead to awful code, but now 
that we
split the subregs out to pseudos it ought to work just fine.

Sadly, even i386 still hasn't been modified to benefit from this work...


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860