This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/17503] New: Huge performance regression in invalid_mode_change_p
- From: "drow at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Sep 2004 16:50:54 -0000
- Subject: [Bug target/17503] New: Huge performance regression in invalid_mode_change_p
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
Compiling insn-attrtab.i with compilers from a few weeks ago, this function is
way down the profile. Now it's at the very top.
:bool
:invalid_mode_change_p (unsigned int regno, enum
reg_class class,
: enum machine_mode from_mode)
625 0.1102 55 0.5528 :{ /* invalid_mode_change_p total: 117807 20.7631
4747 47.7085 */
: enum machine_mode to_mode;
: int n;
113 0.0199 17 0.1709 : int start = regno * MAX_MACHINE_MODE;
:
116873 20.5985 4675 46.9849 : EXECUTE_IF_SET_IN_BITMAP (&subregs_of_mode,
start, n,
: if (n >= MAX_MACHINE_MODE + start)
: return 0;
: to_mode = n - start;
: if (CANNOT_CHANGE_MODE_CLASS (from_mode,
to_mode, class))
: return 1;
: );
: return 0;
196 0.0345 0 0.0e+00 :}
I am not positive whether the function is being called more, or just spending
more time in the bitmap, but it looks like the latter - we're creating many more
entries in subregs_of_mode. I selected a random call to invalid_mode_change_p,
and compared the size of the bitmap in both compilers. In the older compiler,
the high entry in the bitmap was around 10,000 bits; in the newer, around 450,000.
The newer compiler was updated this morning.
--
Summary: Huge performance regression in invalid_mode_change_p
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17503