On Tue, Jan 3, 2017 at 4:20 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> 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?
Hmm, that's sort of the opposite of what I had hoped for.. :-/
Is there some way to ask the backend what the preferred type is, then?
(The snide answer, why didn't the s390 ABi define
bool/_Bool/boolean_type_node to be a 32 bit type if 8 bit types are
problematic? But that's of course water under the bridge by now...)
> 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.
Based on the quick audit I did when I wrote the patch, the only time
it's used except as a local temp variable, is for a couple of the
co-array intrinsics, where the corresponding library implementation
actually uses C _Bool (I suspect it has worked by accident if the args
are passed in registers).
> 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
--
Janne Blomqvist
