------- 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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
