http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |avr
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-06-07
CC| |vmakarov at redhat dot com
Ever Confirmed|0 |1
--- Comment #8 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-06-07
13:24:51 UTC ---
(In reply to comment #5)
> That's not very narrow interval. Please bisect what affected it (or what
> affected it most).
CCing Vladimir
It is caused by fix for PR53065 in
http://gcc.gnu.org/viewcvs?view=revision&revision=186770
--- branches/gcc-4_7-branch/gcc/config/avr/avr.h 2012/04/24 15:23:22
186769
+++ branches/gcc-4_7-branch/gcc/config/avr/avr.h 2012/04/24 15:23:46
186770
@@ -394,6 +394,11 @@
#define REGNO_OK_FOR_INDEX_P(NUM) 0
+#define HARD_REGNO_CALL_PART_CLOBBERED(REGNO, MODE) \
+ (((REGNO) < 18 && (REGNO) + GET_MODE_SIZE (MODE) > 18) \
+ || ((REGNO) < REG_Y && (REGNO) + GET_MODE_SIZE (MODE) > REG_Y) \
+ || ((REGNO) < REG_Z && (REGNO) + GET_MODE_SIZE (MODE) > REG_Z))
+
What's really confusing to me is that this macro is called with invalid
registers, i.e with registers that HARD_REGNO_MODE_OK will reject.
If the macro returns false for the invalid registers, the performance
regression goes away.
Vladimir, is it save to return 0 for invalid hard registers?
What's the point with generating different code when invalid registers are
treated differently? As far as I can see the hard register is not about
SUBREGs, it contains a pointer.
