This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] Use the middle-end boolean_type_node
- From: Jakub Jelinek <jakub at redhat dot com>
- To: vogt at linux dot vnet dot ibm dot com, Janne Blomqvist <blomqvist dot janne at gmail dot com>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Tue, 3 Jan 2017 15:20:26 +0100
- Subject: Re: [PATCH] Use the middle-end boolean_type_node
- Authentication-results: sourceware.org; auth=none
- References: <1481662749-31499-1-git-send-email-blomqvist.janne@gmail.com> <20170103141446.GA1354@linux.vnet.ibm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jan 03, 2017 at 03:14:46PM +0100, Dominik Vogt wrote:
> This patch costs several thousand additional instructions in
> Spec2006 on s390x ("lines" = instructions):
>
> 410.bwaves: +28 lines (2 funcs bigger)
> 437.leslie3d: +43 lines (5 funcs bigger)
> 434.zeusmp: +2650 lines (15 funcs bigger)
> 459.GemsFDTD: +65 lines (7 funcs bigger)
> 454.calculix: +474 lines (23 funcs bigger)
> 465.tonto: +2182 lines (221 funcs bigger)
> 481.wrf: +4988 lines (117 funcs bigger)
> 416.gamess: +3723 lines (466 funcs bigger)
>
> s390x has a "compare with immediate and jump relative" instruction
> for 32 bit, but for an 8 bit quantities it needs separate compare
> and jump instructions, e.g.
>
> cijne %r1,0,... <bi_cgstab_block_+0xfe2>
>
> ->
>
> tmll %r1,1
> jne ... <bi_cgstab_block_+0xfe6>
>
> Instead of hard coding a specific type, should one ask the backend
> for the preferred type?
The gfc_init_types change is an ABI change, at least if the fortran FE
bool type is ever stored in memory and accessed by multiple TUs, or
passed as argument etc. And the difference between the C/C++ _Bool/bool
and fortran FE bool has caused lots of issues in the past, so if it can be
the same type, it is preferrable.
Jakub