gcc in f8/x86 using more stack than in rhel5?

[Eric Sandeen]

Jakub Jelinek wrote:
> On Thu, Aug 23, 2007 at 04:20:41PM -0500, Eric Sandeen wrote:
>> I did a quick experiment, and it seems that by and large, gcc in f8 (gcc
>> version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack
>> when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105
>> (Red Hat 4.1.1-52))  There are a few functions using less, too, though.
>>
>> After much checkstack output frobbing:
>>
>> function [module] : old : new : delta
>> --------------------------------------
>> acpi_add_single_object [vmlinux]: 156 160 : 4
>> acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4
>> adi_connect [adi]: 144 148 : 4
>> aes_decrypt [aes]: 140 144 : 4
>> ahc_pci_config [aic7xxx]: 152 148 : -4
>> ata_do_eh [libata]: 292 304 : 12
>> aty128_probe [aty128fb]: 272 276 : 4
>> balance_internal [reiserfs]: 148 160 : 12
>> bond_arp_send_all [bonding]: 132 136 : 4
>> capidtmf_recv_block [divacapi]: 188 192 : 4
>> cciss_update_non_disk_devices [cciss]: 548 552 : 4
>> cfb_copyarea [vmlinux]: 148 144 : -4
>> check_balance [reiserfs]: 268 272 : 4
>> copy_to_user_tmpl [vmlinux]: 400 404 : 4
>> ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4
>> decode_rs16 [reed_solomon]: 220 224 : 4
>> diNewExt [jfs]: 112 108 : -4
>> diva_add_card [divacapi]: 144 156 : 12
>> do_balance [reiserfs]: 308 320 : 12
>> do_cciss_request [cciss]: 544 548 : 4
>> do_con_write [vmlinux]: 160 156 : -4
>> do_tx [eni]: 120 124 : 4
>> ea_dealloc_unstuffed [gfs2]: 116 120 : 4
>> ehci_urb_enqueue [ehci-hcd]: 196 212 : 16
>> ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4
>> ext4_ext_insert_extent [ext4dev]: 144 148 : 4
>> ext4_ext_remove_space [ext4dev]: 120 124 : 4
>> facility_req [divacapi]: 396 392 : -4
>> __fat_readdir [fat]: 252 256 : 4
>> fat_search_long [fat]: 408 412 : 4
>> fetch_frame [cpia]: 184 196 : 12
>> ftdi_elan_status_work [ftdi-elan]: 252 248 : -4
>> gdth_detect [gdth]: 440 436 : -4
>> get_far_parent [reiserfs]: 140 152 : 12
>> hfcpci_interrupt [hisax]: 356 360 : 4
>> hptiop_probe [hptiop]: 152 156 : 4
>> huft_build [vmlinux]: 152 144 : -8
>> ieee80211_master_start_xmit [mac80211]: 176 180 : 4
>> ieee80211_sta_work [mac80211]: 464 476 : 12
>> i_ipmi_request [ipmi_msghandler]: 108 100 : -8
>> inftl_scan_bbt [diskonchip]: 196 200 : 4
>> ip_route_input [vmlinux]: 196 192 : -4
>> ip_setsockopt [vmlinux]: 448 452 : 4
>> isdn_tty_write [isdn]: 160 164 : 4
>> ivtv_process_vbi_data [ivtv]: 116 120 : 4
>> jfs_readdir [jfs]: 348 340 : -8
>> key_schedule [cast5]: 608 596 : -12
>> matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4
>> matroxfb_ioctl [matroxfb_base]: 136 140 : 4
>> mmc_blk_issue_rq [mmc_block]: 360 356 : -4
>> module_verify_signature [vmlinux]: 124 120 : -4
>> myri10ge_xmit [myri10ge]: 112 116 : 4
>> nv_tx_timeout [forcedeth]: 156 144 : -12
>> ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4
>> os_scsi_tape_open [osst]: 180 184 : 4
>> paging32_page_fault [kvm]: 116 108 : -8
>> parse_audio_unit [snd-usb-audio]: 132 144 : 12
>> patch_cmi9880 [snd-hda-intel]: 108 124 : 16
>> pbus_size_mem [vmlinux]: 124 128 : 4
>> pkt_open [pktcdvd]: 556 560 : 4
>> prism2_plx_probe [hostap_plx]: 116 136 : 20
>> qla1280_nvram_config [qla1280]: 128 160 : 32
>> r300_do_cp_cmdbuf [radeon]: 580 572 : -8
>> radeon_check_modes [radeonfb]: 204 212 : 8
>> radeon_get_pllinfo [radeonfb]: 176 192 : 16
>> s2io_add_isr [s2io]: 176 184 : 8
>> savage_dispatch_draw [savage]: 304 308 : 4
>> sd_revalidate_disk [sd_mod]: 156 116 : -40
>> search_by_key [reiserfs]: 256 272 : 16
>> send_s870 [atp870u]: 100 104 : 4
>> service_interrupt [atmel]: 188 192 : 4
>> _snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4
>> snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36
>> snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8
>> snd_mixart_hw_params [snd-mixart]: 268 272 : 4
>> snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4
>> snd_pcm_hw_refine [snd-pcm]: 160 168 : 8
>> snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8
>> snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4
>> sr_probe [sr_mod]: 140 144 : 4
>> start_preview [saa7134]: 212 232 : 20
>> st_ioctl [st]: 128 144 : 16
>> stv680_newframe [stv680]: 176 192 : 16
>> svcauth_gss_accept [auth_rpcgss]: 216 208 : -8
>> sys_copyarea [syscopyarea]: 144 140 : -4
>> sys_init_module [vmlinux]: 232 236 : 4
>> tcp_sendmsg [vmlinux]: 128 120 : -8
>> tcp_v4_do_rcv [vmlinux]: 104 108 : 4
>> tulip_init_one [tulip]: 136 140 : 4
>> tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8
>> txCommit [jfs]: 168 180 : 12
>> udf_get_block [udf]: 412 416 : 4
>> udf_get_filename [udf]: 584 580 : -4
>> write_filehandle [nfsd]: 208 204 : -4
>> xfs_alloc_delrec [xfs]: 132 144 : 12
>> xfs_bmap_btalloc [xfs]: 172 180 : 8
>> xfs_bmbt_delrec [xfs]: 212 216 : 4
>> xfs_bmbt_newroot [xfs]: 132 140 : 8
>> xfs_da_do_buf [xfs]: 188 192 : 4
>> xfs_inobt_delrec [xfs]: 148 152 : 4
>> xfs_inobt_newroot [xfs]: 172 176 : 4
>> xtSearch [jfs]: 104 116 : 12
>> xtUpdate [jfs]: 404 424 : 20
>> zd1201_usbrx [zd1201]: 100 108 : 8
>> ------------------------
>> Functions increased: 79
>> Functions decreased: 25
>> Net change: +432 bytes
>>
>>
>> that starts with checkstack output, so it's only checking functions
>> using > 100 bytes of stack, and then the above is only showing functions
>> with changed stack usage... but from a spot-check, smaller stack-users
>> are affected as well.
>>
>> With 4KSTACKS on x86, I'm afraid this could add up to more problems.
>>
>> Any idea what might be causing this?
> 
> At least for the 4 testcases you've mailed me, there are two different
> causes:
> 1) http://gcc.gnu.org/PR30364
> 2) http://gcc.gnu.org/PR30931
> 
> E.g. snd_emu10k1_init_efx growth is caused by 1), while qla1280_nvram_config
> by 2), the other two I believe are caused by both together.

Any desire to look at some of the smaller deltas, or do you think it's
likely that they are the same issues?  (I think I can find some simple
functions with small stack deltas, if you'd like).

Thanks for looking at this,

-Eric