[PATCH] Use the middle-end boolean_type_node
Dominik Vogt
vogt@linux.vnet.ibm.com
Tue Jan 3 14:14:00 GMT 2017
On Tue, Dec 13, 2016 at 10:59:09PM +0200, Janne Blomqvist wrote:
> Use the boolean_type_node setup by the middle-end instead of
> redefining it. boolean_type_node is not used in GFortran for any
> ABI-visible stuff, only internally as the type of boolean
> expressions. There appears to be one exception to this, namely the
> caf_get* and caf_send* calls which have boolean_type_node
> arguments. However, on the library side they seem to use C _Bool, so I
> suspect this might be a case of a argument mismatch that hasn't
> affected anything so far.
>
> The practical effect of this is that the size of such variables will
> be the same as a C _Bool or C++ bool, that is, on most targets a
> single byte. Previously we redefined boolean_type_node to be a Fortran
> default logical kind sized variable, that is 4 or 8 bytes depending on
> compile options. This might enable slightly more compact code, in case
> the optimizer determines that the result of such a generated
> comparison expression needs to be stored in some temporary location
> rather than being used immediately.
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?
> Regression tested on x86_64-pc-linux-gnu, Ok for trunk?
>
> 2016-12-13 Janne Blomqvist <jb@gcc.gnu.org>
>
> * trans-types.c (gfc_init_types): Don't redefine boolean type node.
> ---
> gcc/fortran/trans-types.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
> index 354308f..e8dafa0 100644
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
> @@ -961,10 +961,6 @@ gfc_init_types (void)
> wi::mask (n, UNSIGNED,
> TYPE_PRECISION (size_type_node)));
>
> - boolean_type_node = gfc_get_logical_type (gfc_default_logical_kind);
> - boolean_true_node = build_int_cst (boolean_type_node, 1);
> - boolean_false_node = build_int_cst (boolean_type_node, 0);
> -
> /* ??? Shouldn't this be based on gfc_index_integer_kind or so? */
> gfc_charlen_int_kind = 4;
> gfc_charlen_type_node = gfc_get_int_type (gfc_charlen_int_kind);
> --
> 2.7.4
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
More information about the Fortran
mailing list