On Tue, Jan 03, 2017 at 09:40:02PM +0200, Janne Blomqvist wrote:
> I do think this is fixable without waiting for potential improved
> hardware.  The vast majority of uses of boolean_type_node in the
> Fortran frontend is code like
> 
>           tmp = fold_build2_loc (input_location, GT_EXPR,
>                                  boolean_type_node, from_len,
>                                  build_zero_cst (TREE_TYPE (from_len)));
>           tmp = fold_build3_loc (input_location, COND_EXPR,
>                                  void_type_node, tmp, extcopy, stdcopy);
> 
> where the result of a boolean expression is returned as a
> boolean_type_node.  This is a more like high-level language semantics,
> whereas on the asm level boolean expressions are of course evaluated
> with integer arithmetic (or are there targets where this is not
> true?).
> 
> So while the Fortran frontend shouldn't redefine the ABI specified
> boolean_type_node, for situations like the above we could instead use
> some fast_scalar_non_abi_bool_type_node (better name suggestions
> welcome?), if we had some mechanism for returning such information
> from the backend? Or is there some universal best choice here?
> 
> Or since boolean types are not actually present at the asm level, what
> is the best choice in cases like the above in order to generate code
> that can be lowered to as efficient code as possible? Should the
> result of the fold_build2_loc be of, say, TREE_TYPE(from_len) instead
> of boolean_type_node (or fast_scalar_non_abi_bool_type_node or
> whatever we come up with)?
> 
> 
> (Repost without html formatting, sorry for the spam)

Well, generally if it helps Fortran on z10, it will likely help C and C++
too, so you probably instead want some type promotion pass which will know
that on the particular target it is beneficial to promote booleans to
32-bits and know under what circumstances (the loads and stores of course
need to remain the same size for ABI reasons, but as soon as you have it in
SSA_NAME, it depends on what you use it for, sometimes it will be beneficial
to promote it, sometimes not.  Of course, that is something that is too late
for GCC 7.

        Jakub

Reply via email to